كيفية المساهمة في Diffusers 🧨

إذا كنت تستخدم وكيل ذكاء اصطناعي للمساهمة، فتأكد من قراءة قسم المساهمات بمساعدة الذكاء الاصطناعي والوكلاء للاطلاع على توقعاتنا وإرشاداتنا.

نحب ❤️ المساهمات من مجتمع المصادر المفتوحة! الجميع مرحب به، وتُقدَّر وتُثمَّن جميع أشكال المشاركة –وليس فقط الكود–. الإجابة على الأسئلة، ومساعدة الآخرين، والتواصل، وتحسين التوثيق كلها ذات قيمة هائلة للمجتمع، فلا تتردد وانضم إلينا إذا كنت مستعدًا لذلك!

نشجع الجميع على البدء بالقول 👋 في قناة Discord العامة لدينا. نناقش أحدث الاتجاهات في نماذج الانتشار، ونطرح الأسئلة، ونعرض المشاريع الشخصية، ونساعد بعضنا البعض في المساهمات، أو نجلس فقط للاستمتاع ☕.

بغضّ النظر عن الطريقة التي تختارها للمساهمة، فإننا نسعى لأن نكون جزءاً من مجتمع مفتوح ومرحّب ولطيف. يرجى قراءة مدونة السلوك لدينا والالتزام بها أثناء تفاعلاتك. كما ننصحك بالاطلاع على المبادئ التوجيهية الأخلاقية التي تُنظّم مشروعنا، ونطلب منك الالتزام بنفس مبادئ الشفافية والمسؤولية.

نقدّر بشكل كبير الملاحظات الواردة من المجتمع، لذا لا تتردد في التعبير عن رأيك إذا كنت تعتقد أن لديك ملاحظات قيّمة يمكن أن تساعد في تحسين المكتبة - فكل رسالة وتعليق وقضية وطلب سحب (PR) يُقرأ ويُؤخذ في الاعتبار.

نظرة عامة

يمكنك المساهمة بعدة طرق، بدءًا من الإجابة على الأسئلة في القضايا والمناقشات وصولاً إلى إضافة نماذج انتشار جديدة إلى المكتبة الأساسية.

فيما يلي، نقدم نظرة عامة على الطرق المختلفة للمساهمة، مرتبة حسب مقدار الالتزام الزمني المطلوب، بترتيب تصاعدي. جميعها قيّمة للمجتمع.

• 1. طرح الأسئلة والإجابة عنها على GitHub Discussions أو على Discord.
• 2. فتح قضايا جديدة على تبويب GitHub Issues.
• 3. الرد على المشكلات في تبويب مشكلات GitHub.
• 4. قم بإصلاح مشكلة بسيطة، مُعلَّمة بوسم “Good first issue”، راجع هنا.
• 5. ساهم في التوثيق.
• 6. انشر خط أنابيب أو نموذجًا على Hub كرمز عن بُعد باستخدام Modular Diffusers.
• 7. ساهم في الأمثلة.
• 8. عالج مشكلة أكثر صعوبة، مُعلَّمةً بوسم “Good second issue”، راجع هنا.
• 9. تولَّ مهمة من برنامج Diffusers MVP.
• 10. أضف خط أنابيب جديدًا، أو نموذجًا، أو مجدولًا إلى المكتبة. في هذه المساهمة، نعمل عادةً بشكل مباشر مع مؤلفي النموذج؛ وبصفتك مساهمًا في المجتمع، ابدأ على “New Pipeline/Model” بدلاً من ذلك. راجع المسائل المفتوحة “New scheduler”، واقرأ Design Philosophy أولاً.

كما ذُكر سابقًا، جميع المساهمات قيّمة للمجتمع. فيما يلي، سنشرح كل مساهمة بتفصيل أكبر قليلًا.

بالنسبة للمساهمات من 4 إلى 10، باستثناء 6 التي توجد على Hub، ستحتاج إلى فتح طلب سحب. يتم شرح كيفية القيام بذلك بالتفصيل في فتح طلب سحب.

1. طرح الأسئلة والإجابة عنها في GitHub Discussions أو على Discord

يمكن طرح أي سؤال أو تعليق يتعلق بمكتبة Diffusers على GitHub Discussions أو على Discord. وتشمل هذه الأسئلة والتعليقات (وليس حصراً):

• تقارير حول تجارب التدريب أو الاستدلال في محاولة لمشاركة المعرفة
• عرض المشاريع الشخصية
• أسئلة حول أمثلة التدريب غير الرسمية
• اقتراحات المشاريع
• ملاحظات عامة
• ملخصات الأوراق
• طلب المساعدة في المشاريع الشخصية التي تُبنى على مكتبة Diffusers
• أسئلة عامة
• أسئلة أخلاقية تتعلق بنماذج الانتشار
• …

كل سؤال يُطرح في GitHub Discussions أو على Discord يشجع المجتمع بنشاط على مشاركة المعرفة علنًا، وقد يساعد في المستقبل مبتدئًا لديه نفس السؤال الذي لديك. يُرجى طرح أي أسئلة قد تكون لديك. وبنفس الروح، فإنك تقدم مساعدة هائلة للمجتمع من خلال الإجابة على مثل هذه الأسئلة، لأنك بهذه الطريقة توثّق المعرفة علنًا ليتعلم منها الجميع.

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

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

2. فتح مشاكل جديدة على تبويب المشاكل في GitHub

تتميز مكتبة 🧨 Diffusers بالمتانة والموثوقية بفضل المستخدمين الذين يُبلّغوننا عن المشكلات التي يواجهونها. لذا، شكرًا لكم على الإبلاغ عن المشكلة.

تذكّر، أن مشكلات GitHub مخصصة للأسئلة التقنية المرتبطة مباشرةً بمكتبة Diffusers، أو تقارير الأخطاء، أو طلبات الميزات، أو الملاحظات على تصميم المكتبة.

باختصار، هذا يعني أن كل ما لا يتعلق بـكود مكتبة Diffusers (بما في ذلك التوثيق) يجب ألا يُطرح كمشكلة، بل على GitHub Discussions أو Discord.

يرجى مراعاة الإرشادات التالية عند فتح مشكلة جديدة:

• تأكد من أنك بحثت لمعرفة ما إذا كان مشكلتك قد طُرح من قبل (استخدم شريط البحث على GitHub تحت Issues).
• يرجى عدم الإبلاغ عن مشكلة جديدة ضمن مشكلة أخرى (متعلقة). إذا كانت هناك مشكلة أخرى ذات صلة وثيقة، يرجى فتح مشكلة جديدة على أي حال وربطها بالمشكلة ذات الصلة.
• تأكد من أن مشكلتك مكتوبة باللغة الإنجليزية.
• تحقق مما إذا كان بإمكانك حل مشكلتك من خلال التحديث إلى أحدث إصدار من Diffusers. قبل نشر مشكلتك، تأكد من أن python -c "import diffusers; print(diffusers.__version__)" أعلى من أحدث إصدار لـ Diffusers أو يطابقه.
• تذكر أن كلما بذلت جهدًا أكبر في فتح مشكلة جديدة، ارتفعت جودة إجابتك وتحسّنت الجودة الإجمالية لمشكلات Diffusers.

تشمل المشكلات الجديدة عادةً ما يلي.

2.1. تقارير أخطاء قابلة للتكرار وأدنى حد

يجب أن يتضمن تقرير الخطأ دائمًا مقتطفًا من الشيفرة قابلًا للتكرار، وأن يكون بأقل قدر ممكن من التفاصيل وبأكثر إيجاز ممكن. يعني هذا بالتفصيل:

• حدّد نطاق الخطأ قدر الإمكان، لا تكتفِ بإرفاق ملف الكود بأكمله.
• قم بتنسيق الكود الخاص بك.
• لا تتضمن أي مكتبات خارجية باستثناء Diffusers التي تعتمد عليها.
• دائمًا قدّم جميع المعلومات الضرورية حول بيئتك؛ ولتحقيق ذلك، يمكنك تشغيل diffusers-cli env في الطرفية ثم نسخ المعلومات المعروضة ولصقها في المشكلة.
• اشرح المشكلة. إذا لم يكن القارئ على دراية بطبيعة المشكلة وسبب اعتبارها مشكلة، فلن يتمكن من حلها.
• دائمًا تأكد من أن القارئ قادر على إعادة إنتاج مشكلتك بأقل جهد ممكن. إذا تعذّر تشغيل مقتطف الكود الخاص بك بسبب غياب مكتبات أو متغيرات غير معرّفة، فلن يتمكن القارئ من مساعدتك. تأكد من أن مقتطف الكود القابل لإعادة الإنتاج هو الأضيق قدر الإمكان ويمكن نسخه ولصقه في واجهة Python بسيطة.
• إذا كان إعادة إنتاج مشكلتك تتطلب نموذجًا و/أو مجموعة بيانات، فتأكد من أن القارئ لديه وصول إلى ذلك النموذج أو مجموعة البيانات. يمكنك دائمًا رفع نموذجك أو مجموعة بياناتك إلى Hub لجعلها قابلة للتنزيل بسهولة. حاول إبقاء نموذجك ومجموعة بياناتك أصغر ما يمكن، لجعل إعادة إنتاج مشكلتك أسهل ما يمكن.

لمزيد من المعلومات، يرجى الاطلاع على قسم كيف تكتب مشكلة جيدة.

يمكنك فتح تقرير خطأ هنا.

2.2. طلبات الميزات

تعتمد طلبات الميزات العالمية على النقاط التالية:

1. الدافع أولاً:

• هل يرتبط الأمر بمشكلة أو إحباط مع المكتبة؟ إن كان كذلك، يرجى توضيح السبب. يُفضّل تقديم مقتطف من الشيفرة يوضح المشكلة.
• هل يتعلق بشيء ستحتاجه لمشروع ما؟ يسعدنا أن نسمع منك!
• هل هو شيء عملت عليه وترى أنه قد يفيد المجتمع؟ رائع! أخبرنا عن المشكلة التي حلتها لك.

2. اكتب فقرة كاملة تصف الميزة؛
3. قدّم مقتطف كود يوضح استخدامه المستقبلي؛
4. في حال كان هذا الأمر متعلقًا ببحث علمي، يرجى إرفاق رابط؛
5. أرفق أي معلومات إضافية (رسومات، لقطات شاشة، إلخ) تعتقد أنها قد تكون مفيدة.

يمكنك فتح طلب ميزة هنا.

2.3 الملاحظات

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

يمكنك فتح مشكلة تتعلق بالملاحظات هنا.

2.4 أسئلة تقنية

تتعلق الأسئلة التقنية بشكل رئيسي بالسبب وراء كتابة جزء معين من كود المكتبة بطريقة معينة، أو بما يفعله جزء محدد من الكود. يرجى التأكد من تضمين رابط إلى الكود المعني، وتقديم تفاصيل حول سبب صعوبة فهم هذا الجزء من الكود.

يمكنك فتح مشكلة تتعلق بسؤال تقني هنا.

2.5 اقتراح إضافة نموذج أو مجدول أو خط أنابيب جديد

إذا أصدر مجتمع نماذج الانتشار نموذجًا أو خط أنابيب أو مجدولًا جديدًا ترغب في رؤيته في مكتبة Diffusers، يرجى تقديم المعلومات التالية:

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

كما لا تنسَ الإشارة إلى المؤلف الأصلي للمكوّن (النموذج، المجدول، خط الأنابيب، إلخ) عبر اسم المستخدم على GitHub إن أمكنك العثور عليه.

إذا كنت ترغب في إضافة النموذج إلى Diffusers بنفسك، فراجع نشر خط أنابيب أو نموذج على Hub وإضافة خطوط أنابيب ونماذج ومجدولات.

يمكنك فتح طلب لنموذج/خط أنابيب/مجدول هنا.

3. الرد على المشكلات في تبويب المشكلات على GitHub

قد يتطلب الرد على المشكلات في GitHub بعض المعرفة التقنية بـ Diffusers، لكننا نشجع الجميع على المحاولة حتى لو لم تكن متأكدًا بنسبة 100% من صحة إجابتك. بعض النصائح لتقديم إجابة عالية الجودة على مشكلة:

• كن موجزًا وأقل ما يمكن.
• التزم بالموضوع. يجب أن يقتصر الرد على المشكلة على المشكلة فقط.
• قدّم روابط إلى الأكواد أو الأوراق البحثية أو المصادر الأخرى التي تثبت أو تدعم وجهة نظرك.
• أجب بالكود. إذا كان مقتطف كود بسيط هو الإجابة على المشكلة أو يُظهر كيفية حلها، يرجى تقديم مقتطف كود قابل للتكرار بالكامل.

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

إذا كنت قد تأكدت من أن تقرير الخطأ المُصدر صحيح ويتطلب إجراء تصحيح في الشيفرة المصدرية، فيُرجى الاطلاع على الأقسام التالية.

بالنسبة لجميع المساهمات، باستثناء 6، تحتاج إلى فتح طلب سحب. يشرح قسم فتح طلب سحب كيفية القيام بذلك.

4. إصلاح مشكلة “جيدة للمبتدئين”

يتم تحديد المشكلات الجيدة للمبتدئين بوسم مشكلة جيدة للمبتدئين. وعادةً ما يشرح الوصف كيفية مظهر الحل المقترح لتسهيل عملية الإصلاح. إذا لم تُغلق المشكلة بعد وترغب في محاولة إصلاحها، يمكنك ببساطة ترك رسالة تقول “أود محاولة معالجة هذه المشكلة”. وعادةً ما تكون هناك ثلاثة سيناريوهات:

• أ.) يقدّم وصف المشكلة بالفعل إصلاحًا مقترحًا. في هذه الحالة، وإذا كان الحل منطقيًا بالنسبة لك، يمكنك فتح طلب سحب (PR) أو طلب سحب مسودة (draft PR) لإصلاحه.
• ب.) لا يقترح وصف المشكلة إصلاحًا. في هذه الحالة، اقترح إصلاحًا بنفسك في تعليق على المشكلة. يكفي بضع جمل تصف النهج. انتظر حتى يؤكد أحد أعضاء فريق Diffusers ذلك قبل فتح طلب سحب (PR).
• c.) يوجد بالفعل طلب سحب مفتوح لإصلاح المشكلة، لكن المشكلة لم تُغلق بعد. إذا أصبح طلب السحب قديمًا، يمكنك ببساطة فتح طلب سحب جديد وربطه بطلب السحب القديم. غالبًا ما تصبح طلبات السحب قديمة إذا لم يعد المساهم الأصلي الذي أراد إصلاح المشكلة قادرًا على إيجاد الوقت للمتابعة. يحدث هذا كثيرًا في المشاريع مفتوحة المصدر وهو أمر طبيعي جدًا. في هذه الحالة، سيكون المجتمع سعيدًا جدًا إذا حاولت مرة أخرى واستفدت من المعرفة الموجودة في طلب السحب الحالي. إذا كان هناك طلب سحب بالفعل وهو نشط، يمكنك مساعدة المؤلف بتقديم اقتراحات، أو مراجعة طلب السحب، أو حتى السؤال عما إذا كان بإمكانك المساهمة في طلب السحب.

5. المساهمة في التوثيق

المكتبة الجيدة دائمًا تمتاز بتوثيق جيد! غالبًا ما يُعد التوثيق الرسمي من أوائل نقاط التفاعل للمستخدمين الجدد للمكتبة، ولذلك فإن المساهمة في التوثيق تُعد مساهمة ذات قيمة عالية.

يمكن أن يتخذ المساهمة في المكتبة أشكالاً متعددة:

• تصحيح الأخطاء الإملائية أو النحوية.
• صحّح التنسيق غير الصحيح لسطر التوثيق. إذا لاحظت أن التوثيق الرسمي يظهر بشكل غير طبيعي أو أن رابطًا ما مكسور، فسيسعدنا كثيرًا أن تخصص بعض الوقت لتصحيحه.
• صحّح الشكل أو الأبعاد لمُدخل أو مُخرَج متجه في توثيق الدالة.
• وضّح التوثيق الذي يصعب فهمه أو يحتوي على أخطاء.
• تحديث أمثلة الأكواد القديمة.
• ترجمة التوثيق إلى لغة أخرى.

كل ما يظهر على صفحة مستندات Diffusers الرسمية هو جزء من التوثيق الرسمي ويمكن تصحيحه أو تعديله في مصدر التوثيق المعني.

يرجى الاطلاع على هذه الصفحة حول كيفية التحقق من التغييرات المُجراة على التوثيق محليًا.

6. نشر خط أنابيب أو نموذج على الـ Hub

مع Modular Diffusers، يمكن أن يعيش خط أنابيب ككود عن بُعد في أي مستودع على Hub. يمكن لأي شخص تحميله باستخدام from_pretrained(..., trust_remote_code=True)، دون انتظار إصدار جديد من Diffusers. إذا كنت مساهماً في المجتمع تقدم خط أنابيب أو نموذجاً جديداً، فابدأ من هنا. راجع custom blocks لنشر خط أنابيب وcustom models لنشر نموذج.

أخبرونا تحت طلب النموذج المطابق (افتحوا طلباً جديداً إن لم يوجد): نقدم ملاحظاتنا حول التنفيذ ونُبرز النسخ التي نفضلها في مجموعة Community Modular Diffusers Blocks. ومن هناك نقرر كيفية دعم النموذج في المكتبة: قد ندمج نسختكم في النسخة الرئيسية، أو نعمل مع المؤلفين على نسخة رسمية، أو نوجّه المستخدمين ببساطة إلى نسختكم. أخبرونا أيضاً عن أي عقبات واجهتموها على طول الطريق: واجهات برمجة تطبيقات مربكة، توثيق ناقص، أخطاء برمجية. تلك الملاحظات ذات قيمة لدينا بقدر قيمة خط الأنابيب نفسه.

7. المساهمة في أمثلة التدريب

أمثلة Diffusers هي مجموعة من سكربتات التدريب الموجودة في examples.

ندعم نوعين من أمثلة التدريب:

• أمثلة التدريب الرسمية
• أمثلة تدريب البحث

تقع أمثلة التدريب البحثية في examples/research_projects بينما تشمل أمثلة التدريب الرسمية جميع المجلدات الموجودة تحت examples باستثناء مجلدي research_projects وcommunity. يتم صيانة أمثلة التدريب الرسمية من قبل صانعي Diffusers الأساسيين، بينما يتم صيانة أمثلة التدريب البحثية من قبل المجتمع. والسبب في ذلك هو نفس السبب الذي يجعل المكتبة تحافظ على مجموعة صغيرة من خطوط الأنابيب الرسمية وخطوط الأنابيب المجتمعية نشطة على Hub: فليس من الممكن لصانعي الأساسيين صيانة جميع طرق التدريب الممكنة لنماذج الانتشار. إذا اعتبر صانعو Diffusers الأساسيون والمجتمع أن نهج تدريب معين تجريبي للغاية أو غير شائع بما يكفي، فيجب وضع كود التدريب المقابل في مجلد research_projects وصيانته من قبل المؤلف.

تتكون أمثلة التدريب والبحث الرسمية من مجلد يحتوي على سكربت تدريب واحد أو أكثر، وملف requirements.txt، وملف README.md. ولكي يتمكن المستخدم من الاستفادة من أمثلة التدريب، يجب استنساخ المستودع:

git clone https://github.com/huggingface/diffusers

وكذلك لتثبيت جميع التبعيات الإضافية المطلوبة للتدريب:

cd diffusers
pip install -r examples/<your-example-folder>/requirements.txt

لذلك، عند إضافة مثال، يجب أن يحدد ملف requirements.txt جميع تبعيات pip المطلوبة لمثال التدريب الخاص بك، بحيث يمكن للمستخدم تشغيل سكربت تدريب المثال بعد تثبيت جميع تلك التبعيات. راجع، على سبيل المثال، ملف requirements.txt الخاص بـ DreamBooth.

يجب أن تلتزم أمثلة التدريب في مكتبة Diffusers بالفلسفة التالية:

• يجب أن يكون كل الكود اللازم لتشغيل الأمثلة موجودًا في ملف Python واحد.
• يجب أن يكون بإمكان المرء تشغيل المثال من سطر الأوامر باستخدام python <your-example>.py --args.
• يجب أن تبقى الأمثلة بسيطة وتعمل كـمثال على كيفية استخدام Diffusers للتدريب. الغرض من سكريبتات الأمثلة ليس إنشاء نماذج انتشار متطورة، بل إعادة إنتاج مخططات التدريب المعروفة دون إضافة الكثير من المنطق المخصص. وكنتيجة ثانوية لهذا المبدأ، تسعى أمثلتنا أيضاً إلى أن تكون مواد تعليمية جيدة.

لمساهمة مثال، يُوصى بشدة بالاطلاع على الأمثلة الموجودة مسبقًا مثل dreambooth للحصول على فكرة عن الشكل الذي يجب أن تكون عليه. ننصح المساهمين بقوة باستخدام مكتبة Accelerate لأنها متكاملة بشكل وثيق مع Diffusers. بمجرد أن يعمل سكريبت المثال، يرجى التأكد من إضافة README.md شامل يوضح كيفية استخدام المثال بالضبط. يجب أن يتضمن هذا الملف:

• مثال على أمر لتشغيل السكربت التجريبي كما هو موضح هنا.
• رابط إلى بعض نتائج التدريب (السجلات، النماذج، إلخ) تُظهر ما يمكن للمستخدم توقعه كما هو موضح هنا.
• إذا كنت تضيف مثال تدريب غير رسمي/بحثي، يرجى عدم نسيان إضافة جملة تفيد أنك المسؤول عن صيانة هذا المثال التدريبي، مع تضمين اسم حسابك على git كما هو موضح هنا.

إذا كنت تساهم في أمثلة التدريب الرسمية، فتأكد أيضًا من إضافة اختبار إلى مجلدها، مثل examples/dreambooth/test_dreambooth.py. هذا ليس ضروريًا لأمثلة التدريب غير الرسمية.

8. إصلاح مشكلة “جيدة من الدرجة الثانية”

تُوسم المشكلات الجيدة الثانية بوسم مشكلة جيدة ثانية. وعادةً ما تكون أكثر تعقيدًا في الحل من المشكلات الجيدة الأولى، حيث تمنح الوصف إرشادات أقل حول الإصلاح، وتتطلب فهمًا كافيًا للمكتبة.

إذا كنت مهتمًا بالتعامل مع مشكلة ثانية جيدة، فشارك رأيك في المشكلة والمنهجية التي تنوي اتباعها كتعليق، في بضع جمل، واحصل على موافقة من أحد المشرفين قبل فتح طلب الدمج. إذا كان قد تم فتح طلب دمج بالفعل للمشكلة لكن لم يتم دمجه، فتأكد من فهم السبب قبل اقتراح شيء جديد.

9. التعامل مع مشكلة MVP في Diffusers

يُدرج برنامج Diffusers MVP المشكلات التي نرغب فيها أكثر في الحصول على المساعدة. تعمل هذه المشكلات مثل مشكلات "Good second issues"، لكنها أصعب وتستغرق وقتًا أطول، ويكافئ البرنامج المساهمين الذين يتولون معالجتها. شارك مقاربتك كتعليق أولاً واحصل على تأكيد من أحد المشرفين قبل فتح طلب الإرسال. كما يتضمن البرنامج مسار الأفكار: أخبرنا بفكرة واحدة ستزيد من تأثير Diffusers، في بضع جمل وبدون تفاصيل التنفيذ.

10. إضافة خطوط الأنابيب والنماذج والمجدول

إذا كنت مؤلف النموذج، يرجى التواصل معنا حتى نتمكن من تنسيق عملية الدمج معك: افتح طلب ميزة، أو أضف تعليقًا إذا كان هناك طلب مفتوح بالفعل.

إذا كنت مساهماً في المجتمع، فابدأ أولاً بإنشاء مستودع على Hub، راجع نشر خط أنابيب أو نموذج على Hub، وأخبرنا في طلب الميزة أنك مهتم بدمجها في المشروع الرئيسي.

تُعد خطوط الأنابيب والنماذج ومجدولات الوقت أهم مكونات مكتبة Diffusers. توفر وصولاً سهلاً إلى تقنيات الانتشار الرائدة، مما يتيح للمجتمع بناء تطبيقات ذكاء اصطناعي توليدي قوية.

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

عند إصدار دعم لنموذج أو خط أنابيب جديد

قد يُضمَّن نموذج أو خط أنابيب جديد في إصدار ما إذا قمت بتنسيق عملية الدمج مع فريق Diffusers مسبقًا. لا تتردد في التواصل معنا، إما عبر فتح مشكلة (issue) في مستودع Diffusers أو عبر إرسال بريد إلكتروني إلى [email protected].

لا يتم إصدار نسخة جديدة تلقائياً عند دمج طلب سحب نموذج أو خط أنابيب. قبل الإصدار، يتحقق المسؤولون أولاً من اكتمال التكامل ومن نجاح اختبارات الإصدار.

عادةً ما يُدمج دعم النموذج أو خط المعالجة الجديد في الإصدار الفرعي التالي. يتم دمج التكامل في main ويُنشأ فرع الإصدار منه. يحتوي الإصدار على جميع التغييرات المدمجة منذ الإصدار السابق، وليس فقط تكامل النموذج أو خط المعالجة.

تُبرز ملاحظات الإصدار النموذج أو خط الأنابيب الجديد، كما تلخص التغييرات الأخرى المضمنة في الإصدار. وتُخصص إصدارات التصحيح عادةً لإصلاحات الإصدار الموجود مسبقًا.

تحتوي مكتبة Diffusers على بعض طلبات الميزات المفتوحة لجميع المكونات الثلاثة - لا تتردد في الاطلاع عليها إذا كنت لا تعرف بعد المكون المحدد الذي ترغب في إضافته:

• النموذج أو خط الأنابيب
• المجدول

قبل إضافة أيٍّ من المكونات الثلاثة، يُوصى بشدة بقراءة دليل الفلسفة لفهم أفضل لتصميم أيٍّ من المكونات الثلاثة. يرجى العلم أننا لا نستطيع دمج إضافات النماذج أو المجدول أو خطوط الأنابيب التي تنحرف بشدة عن فلسفتنا التصميمية، لأن ذلك سيؤدي إلى عدم اتساق في واجهة برمجة التطبيقات. إذا كنت لا توافق بشكل أساسي على خيار تصميمي معين، فيرجى فتح قضية ملاحظات بدلاً من ذلك حتى يمكن مناقشة ما إذا كان ينبغي تغيير نمط التصميم/الخيار التصميمي المحدد في جميع أنحاء المكتبة، وما إذا كان ينبغي تحديث فلسفتنا التصميمية. الاتساق عبر المكتبة مهم جداً بالنسبة لنا.

يرجى التأكد من إضافة روابط إلى قاعدة الأكواد الأصلية/الورقة البحثية في طلب الدمج (PR)، ومن الأفضل أيضًا التواصل مباشرة مع المؤلف الأصلي على طلب الدمج حتى يتمكن من متابعة التقدم والإجابة عن الأسئلة المحتملة.

إذا كنت غير متأكد أو عالِقًا في طلب الإرسال، فلا تتردد في ترك رسالة تطلب فيها مراجعة أولى أو مساعدة.

تم النسخ من mechanism

ميزة فريدة ومهمة يجب فهمها عند إضافة أي كود خط أنابيب أو نموذج أو مجدول هي آلية # Copied from. ستجد هذه الآلية في جميع أنحاء قاعدة أكواد Diffusers، والسبب في استخدامها هو إبقاء قاعدة الأكواد سهلة الفهم والصيانة. وضع علامة على الكود بآلية # Copied from يجبر الكود المُعلَّم على أن يكون مطابقاً تماماً للكود الذي نُسخ منه. وهذا يسهّل تحديث التغييرات ونشرها عبر العديد من الملفات كلما قمت بتشغيل make fix-copies.

على سبيل المثال، في مثال الشيفرة أدناه، StableDiffusionPipelineOutput هو الشيفرة الأصلية بينما يستخدم AltDiffusionPipelineOutput آلية # Copied from لنسخها. الفارق الوحيد هو تغيير بادئة الفئة من Stable إلى Alt.

# Copied from diffusers.pipelines.stable_diffusion.pipeline_output.StableDiffusionPipelineOutput with Stable->Alt
class AltDiffusionPipelineOutput(BaseOutput):
    """
    Output class for Alt Diffusion pipelines.

    Args:
        images (`List[PIL.Image.Image]` or `np.ndarray`)
            List of denoised PIL images of length `batch_size` or NumPy array of shape `(batch_size, height, width,
            num_channels)`.
        nsfw_content_detected (`List[bool]`)
            List indicating whether the corresponding generated image contains "not-safe-for-work" (nsfw) content or
            `None` if safety checking could not be performed.
    """

للمزيد من التفاصيل، اقرأ هذا القسم من منشور المدونة ~لا تكرر نفسك*.

كيفية كتابة مشكلة جيدة

كلما كانت المشكلة التي تكتبها أفضل، زادت احتمالات حلها بسرعة.

1. تأكد من أنك استخدمت القالب الصحيح لمشكلتك. يمكنك الاختيار بين تقرير خطأ، طلب ميزة، ملاحظات حول تصميم واجهة برمجة التطبيقات، إضافة نموذج/خط أنابيب/مجدول جديد، أو مشكلة فارغة. تأكد من اختيار القالب الصحيح عند فتح مشكلة جديدة. أسئلة الاستخدام تنتمي إلى GitHub Discussions وليس إلى مشكلة.
2. كن دقيقًا: امنح مشكلتك عنوانًا مناسبًا. حاول صياغة وصف المشكلة بأبسط شكل ممكن. كلما كنت أكثر دقة عند تقديم المشكلة، قلّ الوقت المطلوب لفهمها وحلّها على الأرجح. تأكد من فتح مشكلة واحدة فقط لكل مشكلة، وليس لمشكلات متعددة. إذا اكتشفت عدة مشكلات، فافتح عدة مشكلات ببساطة. إذا كانت مشكلتك خطأ برمجيًا، فحاول أن تكون دقيقًا قدر الإمكان بشأن طبيعة الخطأ - فلا تكتفِ بكتابة «خطأ في diffusers».
3. إمكانية التكرار: لا يوجد مقتطف كود قابل للتكرار == لا يوجد حل. إذا واجهت خطأً، يجب على المسؤولين عن المشروع أن يكونوا قادرين على إعادة إنتاجه. تأكد من تضمين مقتطف كود يمكن نسخه ولصقه في مُفسّر Python لإعادة إنتاج المشكلة. تأكد من أن مقتطف الكود يعمل، أي أنه لا توجد استيرادات مفقودة أو روابط مفقودة إلى الصور، ... يجب أن يحتوي تقريرك على رسالة خطأ و مقتطف كود يمكن نسخه ولصقه دون أي تغييرات لإعادة إنتاج نفس رسالة الخطأ تمامًا. إذا كان تقريرك يستخدم أوزان نموذج محلية أو بيانات محلية لا يمكن للقارئ الوصول إليها، فلا يمكن حل المشكلة. إذا لم تتمكن من مشاركة بياناتك أو نموذجك، فحاول إنشاء نموذج وهمي أو بيانات وهمية.
4. بسيط: حاول مساعدة القارئ قدر الإمكان على فهم المشكلة بأسرع وقت ممكن من خلال الإيجاز قدر المستطاع. احذف جميع الأكواد / جميع المعلومات غير ذات الصلة بالمسألة. إذا اكتشفت خطأً، فحاول إنشاء مثال كود أسهل ما يمكن لإظهار مشكلتك، ولا تُلصق سير عملك بأكمله في المشكلة بمجرد اكتشافك للخطأ. على سبيل المثال، إذا كنت تدرب نموذجًا واجهت خطأً في نقطة معينة أثناء التدريب، فيجب أن تحاول أولاً فهم الجزء المسؤول عن الخطأ في كود التدريب ومحاولة إعادة إنتاجه بسطرين من الكود. حاول استخدام بيانات وهمية بدلاً من مجموعات البيانات الكاملة.
5. السياق: أخبرنا بما كنت تعمل عليه عندما واجهت الخلل أو احتجت إلى الميزة، مثل تطبيق مبني على Diffusers، أو مشروع بحثي، أو وكيل (Agent) شغّلته للعثور على أخطاء في المكتبة. جملة أو جملتان تكفيان، ويُرحَّب برابط إلى المشروع. نتلقى عددًا من القضايا وطلبات الدمج يتجاوز قدرتنا على التعامل معها دفعة واحدة، لذا يساعدنا السياق في تحديد الأولويات بناءً على الأثر.
6. أضِف الروابط. إذا كنت تشير إلى تسمية أو طريقة أو نموذج معين، فتأكد من توفير رابط حتى يتمكن القارئ من فهم ما تقصده بشكل أفضل. إذا كنت تشير إلى طلب سحب (PR) أو مشكلة (issue) محددة، فتأكد من ربطها بمشكلتك. لا تفترض أن القارئ يعرف ما تتحدث عنه. كلما أضفت المزيد من الروابط إلى مشكلتك كان ذلك أفضل.
7. تنسيق. تأكد من تنسيق مشكلتك بشكل جيد من خلال تنسيق الأكواد وفق صياغة كود بايثون، ورسائل الخطأ وفق صياغة كود عادي. راجع وثائق تنسيق GitHub الرسمية لمزيد من المعلومات.
8. فكّر في مشكلتك لا بوصفها تذكرة يجب حلّها، بل بوصفها مدخلًا جميلًا في موسوعة مكتوبة بعناية. كل مشكلة تُضاف هي مساهمة في المعرفة المتاحة للعامة. فبإضافة مشكلة مكتوبة بشكل جيد، لا تسهّل على المُحافظين حلّ مشكلتك فحسب، بل تساعد المجتمع بأكمله على فهم جانب معين من المكتبة بشكل أفضل.

كيفية كتابة طلب دمج جيد

1. ابدأ دائمًا من مشكلة. ابحث عن المشكلة التي يعالجها طلب الإرسال الخاص بك، أو افتح واحدة إذا لم يفعل أحد ذلك بعد، ومنح المُحافظين فرصة للرد قبل كتابة أي كود. سير العمل الذي يعمل بشكل أفضل بالنسبة لنا هو فتح مشكلة، ثم مناقشة الحل، ثم طلب إرسال مبني على تلك المناقشة. يتيح لنا ذلك التركيز على المشكلات الأكثر تأثيرًا، والاتفاق على النطاق قبل وجود الكود، وتجنب العمل المكرر. اذكر رقم المشكلة في وصف طلب الإرسال (مثلًا Fixes #1234) حتى يتم ربط الاثنين.
2. كن كالسحلية المتلوّنة. افهم أنماط التصميم والقواعد النحوية الموجودة، وتأكد من أن إضافاتك في الكود تندمج بسلاسة مع قاعدة الكود الحالية. لن يتم دمج طلبات السحب التي تنحرف بشكل كبير عن أنماط التصميم أو واجهات المستخدم الحالية.
3. كن دقيقًا في تركيزك. يجب أن يعالج طلب الدمج مشكلة واحدة فقط. تأكد من عدم الوقوع في فخ «إصلاح مشكلة أخرى أثناء إضافتها». فمن الأصعب بكثير مراجعة طلبات الدمج التي تحل عدة مشاكل غير مترابطة في آنٍ واحد.
4. عالِج الأنماط، لا الحالات الفردية. قد تمتد مشكلة واحدة عبر ملفات كثيرة: إذا تكرر نفس الخطأ في أنحاء قاعدة الشيفرة، فابحث عن كل حالة منها وأصلحها جميعًا في طلب دمج واحد بنطاق واضح ومنهجي (مثلًا: «إصلاح القيم الافتراضية القابلة للتغيير في جميع المجدولين»)، بدلاً من طلب دمج لكل حالة على حدة.
5. يجب أن يكون عنوان طلب السحب الخاص بك ملخصًا لإسهامه. للإشارة إلى أن العمل قيد التنفيذ، ضع بادئة [WIP] قبل العنوان؛ وهذا يمنع تكرار العمل ويفصل طلب السحب عن الطلبات الجاهزة للدمج.
6. حاول صياغة نصك وتنسيقه كما هو موضح في كيف تكتب مشكلة جيدة.
7. راجع الفرق الخاص بك قبل فتح طلب الدمج. اقرأه كما سيفعل المراجع وقوّم ما تجده. ننصح بشدة بتشغيل مهارة self-review: فهي تطبّق المعايير نفسها التي يستخدمها مراجع CI الخاص بـ@claude. اضبط وكيلك كما هو موصوف في البرمجة مع وكلاء الذكاء الاصطناعي واتبع إرشادات المساهمات بمساعدة الذكاء الاصطناعي والوكلاء. اذكر في الوصف الملاحظات التي تركتها عمدًا كما هي، حتى يدرك المراجع أنها قرار متعمد وليس إغفالًا.
8. تأكد من نجاح الاختبارات الموجودة مسبقًا.
9. أضِف اختبارات ذات تغطية عالية. لا يوجد اختبار جودة = لا يوجد دمج.

• إذا كنت تضيف اختبارات جديدة @slow، فتأكد من نجاحها باستخدام RUN_SLOW=1 python -m pytest tests/test_my_new_model.py. لا يشغّل CircleCI الاختبارات البطيئة، لكن GitHub Actions يشغّلها كل ليلة!

10. يجب أن تحتوي جميع الطرق العامة على سلاسل توثيق (docstrings) مفيدة تعمل بشكل جيد مع تنسيق Markdown. راجع pipeline_latent_diffusion.py كمثال.
11. نظرًا للنمو السريع للمستودع، من المهم التأكد من عدم إضافة ملفات قد تُثقل المستودع بشكل كبير. ويشمل ذلك الصور والفيديوهات وملفات غير النصية الأخرى. نفضّل الاعتماد على مجموعة بيانات dataset مستضافة على hf.co مثل hf-internal-testing أو huggingface/documentation-images لوضع هذه الملفات. إذا كان المساهمة خارجية، فلا تتردد في إضافة الصور إلى طلب الإرسال الخاص بك واطلب من عضو في Hugging Face نقل صورك إلى هذه المجموعة.

كيفية فتح طلب دمج

قبل كتابة أي كود، ننصحك بشدة بالبحث في طلبات الدمج (PRs) أو المشكلات (issues) الموجودة للتأكد من أن أحداً لا يعمل على نفس الشيء بالفعل. وإذا كنت غير متأكد، فإن فتح مشكلة (issue) للحصول على بعض الملاحظات هو دائماً فكرة جيدة.

ستحتاج إلى إتقان أساسي لأداة git حتى تتمكن من المساهمة في 🧨 Diffusers. ليست git الأداة الأسهل في الاستخدام، لكنها تمتلك أفضل دليل مرجعي. اكتب git --help في سطر الأوامر واستمتع. إذا كنت تفضّل الكتب، فإن Pro Git مرجع ممتاز.

اتبع هذه الخطوات لبدء المساهمة (إصدارات Python المدعومة):

1. أنشئ نسخةً من المستودع بالنقر على زر "Fork" في صفحة المستودع. يؤدي هذا إلى إنشاء نسخة من الكود تحت حسابك على GitHub.

2. استنسخ فرعك إلى القرص المحلي، وأضف المستودع الأساسي كمستودع بعيد:

   تم النسخ

   $ git clone [email protected]:<your GitHub handle>/diffusers.git
   $ cd diffusers
   $ git remote add upstream https://github.com/huggingface/diffusers.git

3. أنشئ فرعًا جديدًا لاستيعاب تغييرات التطوير الخاصة بك:

   تم النسخ

   $ git checkout -b a-descriptive-name-for-my-changes

لا تعمل على الفرع main.

4. قم بإعداد بيئة التطوير من خلال تنفيذ الأمر التالي في بيئة افتراضية:

   تم النسخ

   $ pip install -e ".[dev]"

إذا كنت قد استنسلت المستودع مسبقًا، فقد تحتاج إلى git pull للحصول على أحدث التغييرات في المكتبة.

5. طوّر الميزات على فرعك.

أثناء عملك على الميزات، يجب أن تتأكد من نجاح مجموعة الاختبارات. يجب عليك تشغيل الاختبارات المتأثرة بتغييراتك على النحو التالي:

$ pytest tests/<TEST_TO_RUN>.py

قبل تشغيل الاختبارات، يرجى التأكد من تثبيت التبعيات المطلوبة للاختبار. يمكنك القيام بذلك باستخدام هذا الأمر:

$ pip install -e ".[test]"

يمكنك أيضًا تشغيل مجموعة الاختبارات الكاملة باستخدام الأمر التالي، لكن الأمر يتطلب جهازًا قويًا لإنتاج نتيجة في وقت معقول، نظرًا للنمو الكبير الذي شهدته مكتبة Diffusers. إليك الأمر لذلك:

$ make test

🧨 يعتمد Diffusers على black وisort لتنسيق كود المصدر بشكل متسق. بعد إجراء التغييرات، طبّق تصحيحات الأسلوب التلقائية والتحقق من الكود الذي لا يمكن أتمتته دفعة واحدة باستخدام:

$ make style

🧨 Diffusers also uses ruff and a few custom scripts to check for coding mistakes. Quality control runs in CI, however, you can also run the same checks with:

$ make quality

بمجرد أن تكون راضياً عن تعديلاتك، أضف الملفات المعدّلة باستخدام git add وأنشئ التزاماً باستخدام git commit لتسجيل تعديلاتك محلياً:

$ git add modified_file.py
$ git commit -m "A descriptive message about your changes."

من الجيد مزامنة نسختك من الكود مع المستودع الأصلي بانتظام. بهذه الطريقة يمكنك التعامل مع التغييرات بسرعة:

$ git pull upstream main

ادفع التغييرات إلى حسابك باستخدام:

$ git push -u origin a-descriptive-name-for-my-changes

6. بمجرد أن تكون راضياً عن النتيجة، انتقل إلى صفحة فرعك على GitHub. انقر على ‘Pull request’ لإرسال تغييراتك إلى مُديري المشروع للمراجعة.

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

الاختبارات

تتضمن المكتبة مجموعة اختبارات شاملة لاختبار سلوك المكتبة وعدة أمثلة. يمكن العثور على اختبارات المكتبة في مجلد الاختبارات.

نفضّل pytest وpytest-xdist لأنها أسرع. من جذر المستودع، إليك كيفية تشغيل الاختبارات باستخدام pytest للمكتبة:

$ python -m pytest -n auto --dist=loadfile -s -v ./tests/

في الواقع، هذا هو بالضبط كيف يتم تنفيذ make test!

يمكنك تحديد مجموعة أصغر من الاختبارات لاختبار الميزة التي تعمل عليها فقط.

بشكل افتراضي، يتم تخطي الاختبارات البطيئة. اضبط متغير البيئة RUN_SLOW على yes لتشغيلها. سيؤدي هذا إلى تنزيل عدة جيجابايت من النماذج — تأكد من امتلاك مساحة كافية على القرص واتصال جيد بالإنترنت، أو الكثير من الصبر!

$ RUN_SLOW=yes python -m pytest -n auto --dist=loadfile -s -v ./tests/

unittest مدعوم بالكامل، وإليك كيفية تشغيل الاختبارات باستخدامه:

$ python -m unittest discover -s tests -t . -v
$ python -m unittest discover -s examples -t examples -v

مزامنة الفرع الرئيسي المنفصل مع الفرع الرئيسي في المصدر (HuggingFace)

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

1. عندما يكون ذلك ممكنًا، تجنّب المزامنة مع المستودع الأصلي باستخدام فرع وطلب دمج على المستودع المنسوخ. وبدلاً من ذلك، ادمج مباشرةً في الفرع الرئيسي للمستودع المنسوخ.
2. إذا كان طلب الدمج ضروريًا تمامًا، فاستخدم الخطوات التالية بعد استخلاص فرعك:

$ git checkout -b your-branch-for-syncing
$ git pull --squash --no-commit upstream main
$ git commit -m '<your message without GitHub references>'
$ git push --set-upstream origin your-branch-for-syncing

دليل الأسلوب

تتبع مكتبة 🧨 Diffusers أسلوب Google في كتابة سلاسل التوثيق.

البرمجة باستخدام وكلاء الذكاء الاصطناعي

يحتفظ المستودع بإعدادات وكيل الذكاء الاصطناعي في .ai/، كما يُنشر كإضافة للوكيل بحيث تُثبَّت مهارات المهام عند الطلب في خطوة واحدة.

• قراءة فقط للمساهمين — يُدير .ai/ المسؤولون الأساسيون. يرجى عدم تعديل الملفات الموجودة تحت .ai/ (أو روابط AGENTS.md / CLAUDE.md على مستوى الجذر، أو المهارات المثبتة في .agents/skills / .claude/skills) في طلب الإرسال الخاص بك. إذا لاحظت نقصًا أو خطأً ما، فافتح مشكلة أو أشر إلى ذلك في طلب الإرسال وسيتولى أحد المسؤولين تحديثه.
• Guidelines — .ai/AGENTS.md يتم تحميله في كل جلسة وكيل عبر الروابط الرمزية الجذرية AGENTS.md / CLAUDE.md ؛ وتُقرأ أدلة المرجع الموجودة تحت .ai/references/ عند الطلب عند اتباع رابط:
  • .ai/AGENTS.md — إرشادات الترميز على المستوى الأعلى
  • .ai/references/models.md — نمط الانتباه، قواعد تنفيذ النموذج، الاتفاقيات الشائعة
  • .ai/references/pipelines.md — اتفاقيات خطوط الأنابيب
  • .ai/references/modular.md — اتفاقيات خطوط الأنابيب المعيارية وقائمة التحقق من التحويل
  • .ai/references/testing.md — طبقات الاختبار المطلوبة، مزيجات المُختبِر، قواعد مكوّنات الوهم
  • .ai/references/review-rules.md — ما يبحث عنه المراجعون
• Skills (تحت .ai/skills/, تُحمَّل عند الطلب للمهام المحددة):
  • model-integration — إضافة نموذج أو خط أنابيب جديد إلى diffusers من البداية إلى النهاية (هيكل الملفات، قائمة التحقق من التكامل، تخطيط الاختبارات، تحويل الأوزان)
  • self-review — راجع تغييراتك مقابل قواعد المشروع قبل فتح طلب دمج
  • diffusers-cli — تشغيل خطوط الأنابيب وفحص المخططات من الطرفية
  • custom-blocks — تغليف فئة فرعية من ModularPipelineBlocks للمركز

بغضّ النظر عن المسار الذي تختاره، اطلب من وكيلك تأكيد إعداداته الخاصة قبل أن تبدأ — python utils/check_ai.py يتحقق من اتساق الأدلة والمهارات، وdiffusers-cli skills list يعرض المهارات التي يمتلكها فعليًا.

المساهمات بمساعدة الذكاء الاصطناعي والوكيلية

نرحّب بالوكلاء (Agents) بالذكاء الاصطناعي للمساهمة في Diffusers. نشجعك على إعداد وكيلك باستخدام دليل الوكلاء الخاص بـ Diffusers واستخدام المهارات المحددة ذات الصلة بالمهام، مثل model-integration وself-review. ثبّت الإضافة (أو المهارات الفردية) كما هو موضح أعلاه، ثم اتبع الدليل لتحديد نطاق مساهمتك وتنفيذها واختبارها ومراجعتها. تبقى مسؤولاً عن فهم التغييرات في طلب الإرسال الخاص بك واختبارها وصيانتها.

نرحّب بالمساهمات المدعومة بالذكاء الاصطناعي، لكن يجب تنسيقها وتحديد نطاقها والتحقق منها للحفاظ على قابلية إدارة عبء المراجعة. قد تُغلق طلبات الدمج التي لا تلتزم بهذه الإرشادات دون إجراء مراجعة تفصيلية.

• تنسيق قبل فتح طلب سحب. ابحث عن مشكلة أو افتح واحدة، راجع طلبات السحب المشابهة (المفتوحة والمغلقة مؤخرًا)، وانتظر تأكيدًا صريحًا من أحد المشرفين على تلك المشكلة قبل فتح طلب سحب. يمنحنا ذلك فرصة لمناقشة النطاق، وتجنب العمل المكرر، والتأكد من المنهجية.
• عالِج الأنماط، لا الحالات الفردية. إذا لاحظت مشكلة متكررة، فابحث في قاعدة الشيفرة عن حالات مشابهة وافتح قضية واحدة بنطاق واضح ومنهجي (مثلًا «إصلاح القيم الافتراضية القابلة للتغيير عبر جميع المجدولين») بدلاً من فتح العديد من القضايا أو طلبات الدمج لكل حالة على حدة.
• المراجعة الذاتية قبل الفتح. نفّذ مهارة self-review — فهي تراجع فرقك (diff) مقابل .ai/references/review-rules.md، وهي المعايير ذاتها التي يستخدمها مراجع CI الخاص بـ @claude — وتعامل مع ما يُبلّغ عنه؛ فهو أداة مساعدة وليست مرجعية حاسمة، وقد يكون مخطئًا. ركّز على المشكلات العالقة التي تبدو منطقية بالنسبة لك، ونظّف الكود الميت أو غير المستخدم قدر الإمكان. إذا كنت لا توافق على اقتراح ما، فلا بأس من تركه ليُناقشه المراجع بعد فتح طلب الدمج (PR) — فالملاحظات التي تشاركها (انظر أدناه) تُخبر المراجع أن ذلك كان قرارًا متعمدًا.
• شارك ملاحظات المراجعة الذاتية الخاصة بك. يُرجى نشر تقرير المراجعة الذاتية النهائي — الجولة التي تعكس الفروقات التي تُقدّمها — على طلب الدمج، في الوصف أو كتعليق، مع تضمين النتائج التي اخترت عمدًا عدم إصلاحها والسبب وراء ذلك. يساعد ذلك المُراجِع على رؤية ما تم فحصه مسبقًا وأي قرارات كانت متعمدة، ويوفّر عادةً جولات عدة من التبادل.
• اجعل تواصلك في طلبات الدمج موجزًا. كل ما يقرؤه المُراجِع في طلب الدمج الخاص بك — الوصف، رسائل الالتزامات، التعليقات والردود، تعليقات الأكواد — يجب أن يكون سهل الفهم على الإنسان. إذا صاغه وكيلك، فلا تكتفِ بمراجعته سريعًا. اقرأه، واطلب من الوكيل تعديله حتى يصبح نصًا منطقيًا وموجزًا كنتَ ستكتبه بنفسك. أنت مؤلف كل ما تنشره.
• Include in the PR description:
  • رابط تنسيق إلى المشكلة أو النقاش الذي اعترف فيه أحد المشرفين بالعمل.
  • أوامر الاختبار التي قمت بتشغيلها ونتائجها (الصق المخرجات ذات الصلة، وليس مجرد «الاختبارات ناجحة»).
  • ملاحظاتك للمراجعة الذاتية (أو رابط إلى تعليق طلب الإرسال الذي يحتوي عليها)، كما هو موضح أعلاه.

إذا كنت مؤلف نموذج أو جزءًا من فريق يقوم رسميًا بصيانة نموذج، فنشجعك على استخدام الوكلاء (agents) لدمج نموذج جديد. اتبع الإعداد الموصى به في المستودع واستخدم مهارة model-integration. تنسيق نطاق العمل مع المشرفين قبل فتح طلب سحب (PR) — راجع إضافة خطوط الأنابيب والنماذج والمجدولين.