Cara berkontribusi pada Diffusers 🧨

Jika Anda menggunakan agen AI untuk berkontribusi, pastikan Anda membaca bagian kontribusi yang dibantu AI dan berbasis agen untuk mengetahui harapan dan pedoman kami.

Kami ❤️ kontribusi dari komunitas open-source! Semua orang dipersilakan, dan semua jenis partisipasi –bukan hanya kode– dihargai dan diapresiasi. Menjawab pertanyaan, membantu orang lain, berinteraksi, dan meningkatkan dokumentasi semuanya sangat berharga bagi komunitas, jadi jangan ragu dan libatkan diri Anda jika Anda siap!

Semua orang didorong untuk memulai dengan mengucapkan 👋 di channel Discord publik kami. Kami membahas tren terbaru dalam model difusi, mengajukan pertanyaan, memamerkan proyek pribadi, saling membantu dalam kontribusi, atau sekadar bersantai ☕.

Bagaimana pun cara Anda memilih untuk berkontribusi, kami berusaha menjadi bagian dari komunitas yang terbuka, ramah, dan penuh kebaikan. Silakan baca code of conduct kami dan perhatikan untuk menghormatinya selama interaksi Anda. Kami juga menyarankan Anda untuk familiar dengan ethical guidelines yang memandu proyek kami dan meminta Anda untuk mematuhi prinsip-prinsip transparansi dan tanggung jawab yang sama.

Kami sangat menghargai umpan balik dari komunitas, jadi jangan ragu untuk bersuara jika Anda memiliki masukan berharga yang dapat membantu meningkatkan pustaka ini - setiap pesan, komentar, masalah, dan pull request (PR) akan dibaca dan dipertimbangkan.

Ikhtisar

Anda dapat berkontribusi dengan berbagai cara, mulai dari menjawab pertanyaan pada issues dan discussions hingga menambahkan model difusi baru ke pustaka inti.

Berikut adalah gambaran umum tentang berbagai cara untuk berkontribusi, diurutkan berdasarkan komitmen waktu yang diperlukan, dari yang terkecil hingga terbesar. Semua cara tersebut bernilai bagi komunitas.

• 1. Bertanya dan menjawab pertanyaan di GitHub Discussions atau di Discord.
• 2. Membuka masalah baru di tab GitHub Issues.
• 3. Menjawab masalah pada tab GitHub Issues.
• 4. Perbaiki masalah sederhana yang ditandai dengan label “Good first issue”, lihat di sini.
• 5. Berkontribusi pada dokumentasi.
• 6. Publikasikan pipeline atau model di Hub sebagai kode jarak jauh dengan Modular Diffusers.
• 7. Kontribusi ke contoh.
• 8. Perbaiki masalah yang lebih sulit, yang ditandai dengan label “Good second issue”, lihat di sini.
• 9. Ambil sebuah isu dari program MVP Diffusers.
• 10. Tambahkan pipeline, model, atau scheduler baru ke pustaka. Untuk kontribusi ini, kami biasanya bekerja langsung dengan para penulis model; sebagai kontributor komunitas, mulailah di Hub (6) terlebih dahulu. Lihat masalah terbuka “New Pipeline/Model” dan “New scheduler”, dan baca Design Philosophy terlebih dahulu.

Seperti yang telah disebutkan sebelumnya, semua kontribusi sangat berharga bagi komunitas. Berikut ini, kami akan menjelaskan setiap kontribusi secara lebih rinci.

Untuk kontribusi 4 hingga 10, kecuali 6 yang berada di Hub, Anda perlu membuka PR. Cara melakukannya dijelaskan secara rinci di Membuka pull request.

1. Bertanya dan menjawab pertanyaan di GitHub Discussions atau di Discord

Setiap pertanyaan atau komentar yang berkaitan dengan pustaka Diffusers dapat diajukan di GitHub Discussions atau di Discord. Pertanyaan dan komentar tersebut mencakup (namun tidak terbatas pada):

• Laporan eksperimen pelatihan atau inferensi dalam upaya berbagi pengetahuan
• Presentasi proyek pribadi
• Pertanyaan untuk contoh pelatihan non-resmi
• Usulan proyek
• Umpan balik umum
• Ringkasan makalah
• Meminta bantuan untuk proyek pribadi yang dibangun di atas pustaka Diffusers
• Pertanyaan umum
• Pertanyaan etis terkait model difusi
• …

Setiap pertanyaan yang diajukan di GitHub Discussions atau di Discord secara aktif mendorong komunitas untuk berbagi pengetahuan secara publik dan sangat mungkin membantu pemula di masa depan yang memiliki pertanyaan yang sama dengan Anda. Silakan ajukan pertanyaan apa pun yang mungkin Anda miliki. Dengan semangat yang sama, Anda memberikan bantuan yang sangat besar bagi komunitas dengan menjawab pertanyaan-pertanyaan tersebut, karena dengan cara ini Anda mendokumentasikan pengetahuan secara publik agar semua orang dapat belajar darinya.

Harap diingat bahwa semakin banyak usaha yang Anda curahkan untuk bertanya atau menjawab, semakin tinggi pula kualitas pengetahuan yang didokumentasikan secara publik. Dengan cara yang sama, pertanyaan yang dirumuskan dengan baik dan dijawab dengan baik akan menciptakan basis data pengetahuan berkualitas tinggi yang dapat diakses oleh semua orang, sementara pertanyaan atau jawaban yang buruk akan mengurangi kualitas keseluruhan basis data pengetahuan publik. Singkatnya, pertanyaan atau jawaban berkualitas tinggi bersifat presisi, ringkas, relevan, mudah dipahami, dapat diakses, dan berformat baik/dirumuskan dengan baik. Untuk informasi lebih lanjut, silakan lihat bagian Cara menulis issue yang baik.

CATATAN tentang channel: GitHub Discussions diindeks oleh mesin pencari dan setiap thread dapat ditautkan, sehingga pertanyaan dan jawaban yang diposting di sana tetap dapat ditemukan oleh orang berikutnya yang memiliki masalah yang sama. Sebaliknya, Discord memiliki format seperti obrolan yang mendorong komunikasi cepat dan langsung. Meskipun kemungkinan besar Anda akan mendapatkan jawaban lebih cepat untuk pertanyaan Anda di Discord, pertanyaan Anda tidak akan terlihat lagi seiring berjalannya waktu, dan jauh lebih sulit untuk menemukan informasi yang diposting cukup lama yang lalu. Oleh karena itu, kami merekomendasikan GitHub Discussions untuk pertanyaan dan jawaban yang dimaksudkan untuk bertahan lama. Jika percakapan di Discord menghasilkan kesimpulan yang menarik, posting hasilnya sebagai diskusi agar pembaca di masa depan dapat menemukannya.

2. Membuka masalah baru di tab masalah GitHub

Perpustakaan 🧨 Diffusers yang kokoh dan andal berkat para pengguna yang memberi tahu kami tentang masalah yang mereka hadapi. Jadi, terima kasih telah melaporkan masalah.

Ingat, masalah GitHub dikhususkan untuk pertanyaan teknis yang langsung berkaitan dengan pustaka Diffusers, laporan bug, permintaan fitur, atau umpan balik tentang desain pustaka.

Singkatnya, ini berarti bahwa segala hal yang tidak berkaitan dengan kode pustaka Diffusers (termasuk dokumentasi) sebaiknya tidak diajukan sebagai issue, melainkan melalui GitHub Discussions atau Discord.

Silakan pertimbangkan pedoman berikut saat membuka masalah baru:

• Pastikan Anda telah mencari apakah masalah Anda sudah pernah ditanyakan sebelumnya (gunakan bilah pencarian di GitHub di bawah Issues).
• Jangan pernah melaporkan masalah baru pada masalah (terkait) lainnya. Jika ada masalah yang sangat terkait, tetap buka masalah baru dan tautkan ke masalah yang terkait.
• Pastikan masalah Anda ditulis dalam bahasa Inggris.
• Periksa apakah masalah Anda mungkin dapat diatasi dengan memperbarui ke versi Diffusers terbaru. Sebelum memposting masalah Anda, pastikan bahwa python -c "import diffusers; print(diffusers.__version__)" lebih tinggi atau sama dengan versi Diffusers terbaru.
• Ingatlah bahwa semakin banyak usaha yang Anda curahkan untuk membuka masalah baru, semakin tinggi kualitas jawaban Anda dan semakin baik kualitas keseluruhan masalah Diffusers.

Isu baru biasanya mencakup hal-hal berikut.

2.1. Laporan bug yang dapat direproduksi dan minimal

Laporan bug harus selalu memiliki potongan kode yang dapat direproduksi dan sesedikit serta sesingkat mungkin. Artinya secara lebih rinci:

• Persempit bug sedapat mungkin, jangan hanya menumpahkan seluruh file kode Anda.
• Format kode Anda.
• Jangan sertakan pustaka eksternal apa pun kecuali Diffusers yang bergantung pada pustaka tersebut.
• Selalu berikan semua informasi yang diperlukan tentang lingkungan Anda; untuk itu, Anda dapat menjalankan: diffusers-cli env di shell Anda dan menyalin-tempel informasi yang ditampilkan ke dalam issue.
• Jelaskan masalahnya. Jika pembaca tidak tahu apa masalahnya dan mengapa itu menjadi masalah, (dia) tidak dapat menyelesaikannya.
• Selalu pastikan pembaca dapat mereproduksi masalah Anda dengan usaha seminimal mungkin. Jika potongan kode Anda tidak dapat dijalankan karena perpustakaan yang hilang atau variabel yang tidak didefinisikan, pembaca tidak dapat membantu Anda. Pastikan potongan kode yang dapat direproduksi Anda sesedikit mungkin dan dapat disalin-tempel ke shell Python sederhana.
• Jika diperlukan model dan/atau dataset untuk mereproduksi masalah Anda, pastikan pembaca memiliki akses ke model atau dataset tersebut. Anda selalu dapat mengunggah model atau dataset Anda ke Hub agar mudah diunduh. Usahakan model dan dataset Anda sesedikit mungkin, agar reproduksi masalah Anda semudah mungkin.

Untuk informasi lebih lanjut, silakan lihat bagian Cara menulis isu yang baik.

Anda dapat membuka laporan bug di sini.

2.2. Permintaan fitur

Permintaan fitur kelas dunia menangani poin-poin berikut:

1. Motivasi terlebih dahulu:

• Apakah ini terkait dengan masalah/kekecewaan terhadap pustaka? Jika ya, silakan jelaskan alasannya. Menyediakan potongan kode yang mendemonstrasikan masalah tersebut adalah yang terbaik.
• Apakah ini terkait dengan sesuatu yang Anda butuhkan untuk sebuah proyek? Kami ingin mendengarnya!
• Apakah ini sesuatu yang Anda kerjakan dan Anda rasa dapat bermanfaat bagi komunitas? Luar biasa! Ceritakan kepada kami masalah apa yang dipecahkan olehnya untuk Anda.

2. Tulis paragraf lengkap yang menjelaskan fitur tersebut;
3. Sediakan cuplikan kode yang mendemonstrasikan penggunaan masa depannya;
4. Jika ini terkait dengan sebuah makalah, silakan lampirkan tautannya;
5. Lampirkan informasi tambahan (gambar, tangkapan layar, dll.) yang menurut Anda dapat membantu.

Anda dapat membuka permintaan fitur di sini.

2.3 Umpan balik

Umpan balik mengenai desain pustaka dan mengapa desain tersebut baik atau tidak baik sangat membantu para pemelihara inti dalam membangun pustaka yang ramah pengguna. Untuk memahami filosofi di balik filosofi desain saat ini, silakan lihat di sini. Jika Anda merasa bahwa pilihan desain tertentu tidak sesuai dengan filosofi desain saat ini, silakan jelaskan alasannya dan bagaimana seharusnya diubah. Jika pilihan desain tertentu terlalu mengikuti filosofi desain, sehingga membatasi kasus penggunaan, jelaskan alasannya dan bagaimana seharusnya diubah. Jika pilihan desain tertentu sangat berguna bagi Anda, silakan juga tinggalkan catatan karena ini merupakan umpan balik yang sangat baik untuk keputusan desain di masa depan.

Anda dapat membuka masalah tentang umpan balik di sini.

2.4 Pertanyaan teknis

Pertanyaan teknis terutama berkaitan dengan mengapa kode tertentu dari pustaka ditulis dengan cara tertentu, atau apa yang dilakukan oleh bagian tertentu dari kode. Pastikan untuk menyertakan tautan ke kode yang dimaksud dan berikan detail mengapa bagian kode ini sulit dipahami.

Anda dapat membuka isu tentang pertanyaan teknis di sini.

2.5 Usulan untuk menambahkan model, penjadwal, atau pipeline baru

Jika komunitas model difusi merilis model, pipeline, atau scheduler baru yang ingin Anda lihat di pustaka Diffusers, silakan berikan informasi berikut:

• Deskripsi singkat tentang pipeline difusi, model, atau scheduler, beserta tautan ke makalah atau rilis publik.
• Tautan ke salah satu implementasi open-source-nya.
• Tautan ke bobot model jika tersedia.

Selain itu, jangan lupa untuk menandai penulis asli komponen (model, scheduler, pipeline, dll.) dengan handle GitHub mereka jika Anda dapat menemukannya.

Jika Anda ingin membawa model ke Diffusers sendiri, lihat Publikasikan pipeline atau model di Hub dan Menambahkan pipeline, model, scheduler.

Anda dapat membuka permintaan untuk model/pipeline/scheduler di sini.

3. Menjawab masalah pada tab masalah GitHub

Menjawab isu di GitHub mungkin memerlukan beberapa pengetahuan teknis tentang Diffusers, tetapi kami mendorong semua orang untuk mencobanya meskipun Anda tidak 100% yakin bahwa jawaban Anda benar. Beberapa tips untuk memberikan jawaban berkualitas tinggi terhadap sebuah isu:

• Sedikit dan minimal mungkin.
• Tetap pada topik. Jawaban untuk masalah tersebut harus berkaitan dengan masalah tersebut dan hanya masalah tersebut.
• Sediakan tautan ke kode, makalah, atau sumber lain yang membuktikan atau mendukung poin Anda.
• Jawab dengan kode. Jika potongan kode sederhana merupakan jawaban atas masalah atau menunjukkan cara menyelesaikan masalah, silakan berikan potongan kode yang sepenuhnya dapat direproduksi.

Selain itu, banyak masalah yang cenderung tidak relevan, duplikat dari masalah lain, atau tidak berkaitan. Sangat membantu bagi para maintainer jika Anda dapat menjawab masalah semacam itu, mendorong penulis masalah untuk lebih spesifik, menyediakan tautan ke masalah yang diduplikasi, atau mengarahkan mereka ke GitHub Discussions atau Discord.

Jika Anda telah memverifikasi bahwa laporan bug yang diterbitkan benar dan memerlukan koreksi pada kode sumber, silakan lihat bagian-bagian berikutnya.

Untuk semua kontribusi, kecuali 6, Anda perlu membuka PR. Bagian Membuka pull request menjelaskan caranya.

4. Memperbaiki “Good first issue”

Isu yang cocok untuk pemula ditandai dengan label Good first issue. Biasanya, isu tersebut sudah menjelaskan bagaimana solusi potensial seharusnya terlihat sehingga lebih mudah diperbaiki. Jika isu belum ditutup dan Anda ingin mencoba memperbaikinya, Anda cukup meninggalkan pesan “I would like to try this issue.”. Biasanya ada tiga skenario:

• a.) Deskripsi masalah sudah mengusulkan perbaikan. Dalam kasus ini, dan jika solusi tersebut masuk akal bagi Anda, Anda dapat membuka PR atau draft PR untuk memperbaikinya.
• b.) Deskripsi masalah tidak mengusulkan perbaikan. Dalam hal ini, usulkan perbaikan Anda sendiri dalam komentar pada masalah tersebut. Beberapa kalimat yang menjelaskan pendekatan sudah cukup. Tunggu hingga seseorang dari tim Diffusers mengonfirmasinya sebelum Anda membuka PR.
• c.) Sudah ada PR terbuka untuk memperbaiki masalah tersebut, tetapi masalahnya belum ditutup. Jika PR tersebut sudah tidak aktif, Anda cukup membuka PR baru dan menautkan ke PR yang tidak aktif tersebut. PR sering kali menjadi tidak aktif jika kontributor asli yang ingin memperbaiki masalah tersebut tiba-tiba tidak lagi memiliki waktu untuk melanjutkan. Hal ini sering terjadi dalam proyek open-source dan sangat wajar. Dalam kasus ini, komunitas akan sangat senang jika Anda mencoba lagi dan memanfaatkan pengetahuan dari PR yang sudah ada. Jika sudah ada PR dan masih aktif, Anda dapat membantu penulisnya dengan memberikan saran, meninjau PR, atau bahkan bertanya apakah Anda dapat berkontribusi pada PR tersebut.

5. Berkontribusi pada dokumentasi

Perpustakaan yang baik selalu memiliki dokumentasi yang baik! Dokumentasi resmi sering menjadi salah satu titik kontak pertama bagi pengguna baru perpustakaan, sehingga berkontribusi pada dokumentasi adalah kontribusi yang sangat berharga.

Kontribusi ke pustaka ini dapat memiliki banyak bentuk:

• Memperbaiki kesalahan ejaan atau tata bahasa.
• Perbaiki format docstring yang salah. Jika Anda melihat bahwa dokumentasi resmi ditampilkan secara aneh atau tautan rusak, kami akan sangat senang jika Anda meluangkan waktu untuk memperbaikinya.
• Perbaiki bentuk atau dimensi tensor input atau output docstring.
• Perjelas dokumentasi yang sulit dipahami atau tidak akurat.
• Perbarui contoh kode yang sudah usang.
• Menerjemahkan dokumentasi ke bahasa lain.

Apa pun yang ditampilkan di halaman dokumentasi resmi Diffusers merupakan bagian dari dokumentasi resmi dan dapat dikoreksi atau disesuaikan di source dokumentasi yang bersangkutan.

Silakan lihat halaman ini tentang cara memverifikasi perubahan yang dibuat pada dokumentasi secara lokal.

6. Terbitkan pipeline atau model di Hub

Dengan Modular Diffusers, sebuah pipeline dapat berada sebagai kode remote di repo Hub mana pun. Siapa pun dapat memuatnya dengan from_pretrained(..., trust_remote_code=True), tanpa harus menunggu rilis Diffusers. Jika Anda adalah kontributor komunitas yang membawa pipeline atau model baru, mulai dari sini. Lihat custom blocks untuk menerbitkan pipeline dan custom models untuk menerbitkan model.

Beritahu kami di bawah permintaan model yang sesuai (buka satu jika belum ada): kami memberikan umpan balik tentang implementasi dan menampilkan yang kami sukai dalam koleksi Community Modular Diffusers Blocks kami. Dari situ kami memutuskan bagaimana mendukung model di pustaka: kami mungkin mengupstream versi Anda, bekerja sama dengan para penulis untuk membuat versi resmi, atau sekadar mengarahkan orang ke versi Anda. Sampaikan juga di mana Anda mengalami hambatan di sepanjang jalan: API yang membingungkan, dokumentasi yang hilang, bug. Umpan balik itu bernilai sama bagi kami dengan pipeline-nya.

7. Berkontribusi pada contoh pelatihan

Contoh Diffusers adalah kumpulan skrip pelatihan yang berada di examples.

Kami mendukung dua jenis contoh pelatihan:

• Contoh pelatihan resmi
• Contoh pelatihan penelitian

Contoh pelatihan riset terletak di examples/research_projects sedangkan contoh pelatihan resmi mencakup semua folder di bawah examples kecuali folder research_projects dan community. Contoh pelatihan resmi dipelihara oleh pemelihara inti Diffusers sedangkan contoh pelatihan riset dipelihara oleh komunitas. Hal ini dilakukan dengan alasan yang sama mengapa pustaka ini mempertahankan sejumlah kecil pipeline resmi dan pipeline komunitas yang aktif di Hub: tidak memungkinkan bagi pemelihara inti untuk memelihara semua metode pelatihan yang mungkin untuk model difusi. Jika pemelihara inti Diffusers dan komunitas menganggap suatu paradigma pelatihan tertentu terlalu eksperimental atau tidak cukup populer, kode pelatihan yang sesuai harus ditempatkan di folder research_projects dan dipelihara oleh penulisnya.

Kedua contoh pelatihan dan penelitian resmi terdiri dari direktori yang berisi satu atau beberapa skrip pelatihan, file requirements.txt, dan file README.md. Agar pengguna dapat memanfaatkan contoh pelatihan, pengguna harus mengkloning repositori:

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

serta untuk menginstal semua dependensi tambahan yang diperlukan untuk pelatihan:

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

Oleh karena itu, saat menambahkan contoh, file requirements.txt harus mendefinisikan semua dependensi pip yang diperlukan untuk contoh pelatihan Anda, sehingga setelah semuanya diinstal, pengguna dapat menjalankan skrip pelatihan dari contoh tersebut. Lihat, misalnya, file requirements.txt DreamBooth.

Contoh pelatihan dari pustaka Diffusers harus mematuhi filosofi berikut:

• Semua kode yang diperlukan untuk menjalankan contoh harus ditemukan dalam satu file Python.
• Seharusnya Anda dapat menjalankan contoh dari baris perintah dengan python <your-example>.py --args.
• Contoh sebaiknya dibuat sederhana dan berfungsi sebagai contoh cara menggunakan Diffusers untuk pelatihan. Tujuan dari skrip contoh adalah bukan untuk membuat model difusi state-of-the-art, melainkan untuk mereproduksi skema pelatihan yang sudah dikenal tanpa menambahkan terlalu banyak logika kustom. Sebagai hasil dari hal ini, contoh kami juga berusaha menjadi bahan edukasi yang baik.

Untuk berkontribusi dengan sebuah contoh, sangat disarankan untuk melihat contoh yang sudah ada seperti dreambooth untuk mendapatkan gambaran tentang bagaimana seharusnya contoh tersebut dibuat. Kami sangat menyarankan kontributor untuk memanfaatkan Accelerate library karena terintegrasi erat dengan Diffusers. Setelah skrip contoh berfungsi, pastikan untuk menambahkan README.md yang komprehensif yang menjelaskan cara menggunakan contoh tersebut secara tepat. README ini harus mencakup:

• Contoh perintah untuk menjalankan skrip contoh seperti yang ditunjukkan di sini.
• Tautan ke beberapa hasil pelatihan (log, model, dll.) yang menunjukkan apa yang dapat diharapkan pengguna, seperti yang ditunjukkan di sini.
• Jika Anda menambahkan contoh pelatihan non-resmi/riset, jangan lupa untuk menambahkan kalimat bahwa Anda memelihara contoh pelatihan ini, yang mencakup handle git Anda seperti yang ditunjukkan di sini.

Jika Anda berkontribusi pada contoh pelatihan resmi, pastikan juga untuk menambahkan tes ke folder-nya, seperti examples/dreambooth/test_dreambooth.py. Hal ini tidak diperlukan untuk contoh pelatihan non-resmi.

8. Memperbaiki “Good second issue”

Isu kedua yang baik ditandai dengan label Good second issue. Biasanya, isu-isu ini lebih rumit untuk diselesaikan daripada Isu pertama yang baik, deskripsinya memberikan panduan yang lebih sedikit mengenai perbaikannya, dan diperlukan pemahaman yang memadai tentang pustaka tersebut.

Jika Anda tertarik untuk menangani masalah kedua yang baik, bagikan pandangan Anda tentang masalah tersebut dan pendekatan yang Anda rencanakan sebagai komentar, dalam beberapa kalimat, dan dapatkan pengakuan dari maintainer sebelum Anda membuka PR. Jika PR sudah dibuka untuk masalah tersebut tetapi tidak digabungkan, lihatlah untuk memahami alasannya sebelum Anda mengusulkan sesuatu yang baru.

9. Menangani masalah MVP Diffusers

Program Diffusers MVP mencantumkan isu-isu yang paling membutuhkan bantuan. Isu-isu ini berfungsi seperti Good second issues, tetapi lebih sulit dan membutuhkan waktu lebih lama, dan program ini memberikan penghargaan kepada kontributor yang mengambilnya. Bagikan pendekatan Anda sebagai komentar terlebih dahulu dan dapatkan pengakuan dari maintainer sebelum Anda membuka PR. Program ini juga memiliki jalur ide: beri tahu kami satu ide yang akan meningkatkan dampak Diffusers, dalam beberapa kalimat dan tanpa detail implementasi.

10. Menambahkan pipeline, model, dan scheduler

Jika Anda adalah penulis model tersebut, silakan hubungi kami agar kami dapat berkoordinasi dengan Anda mengenai integrasi: buka permintaan fitur, atau tinggalkan komentar jika sudah ada yang terbuka.

Jika Anda adalah kontributor komunitas, mulailah dengan repo Hub terlebih dahulu, lihat Menerbitkan pipeline atau model di Hub, dan beri tahu kami di bawah permintaan fitur bahwa Anda tertarik untuk mengupstream-nya.

Pipelines, models, dan schedulers adalah bagian terpenting dari pustaka Diffusers. Mereka menyediakan akses mudah ke teknologi difusi terkini sehingga memungkinkan komunitas untuk membangun aplikasi AI generatif yang kuat.

Dengan menambahkan model, pipeline, atau scheduler baru, Anda mungkin dapat mengaktifkan kasus penggunaan baru yang kuat untuk antarmuka pengguna mana pun yang bergantung pada Diffusers, yang dapat memiliki nilai sangat besar bagi seluruh ekosistem AI generatif.

Ketika dukungan untuk model atau pipeline baru dirilis

Model atau pipeline baru dapat disertakan dalam rilis jika Anda mengoordinasikan integrasi dengan tim Diffusers terlebih dahulu. Silakan hubungi kami, baik melalui issue di repositori Diffusers atau dengan mengirim email ke [email protected].

Rilis tidak terjadi secara otomatis ketika pull request model atau pipeline digabungkan. Sebelum rilis, maintainer terlebih dahulu memeriksa bahwa integrasi telah selesai dan bahwa tes rilis berhasil.

Dukungan untuk model atau pipeline baru biasanya dimasukkan ke dalam rilis minor berikutnya. Integrasi digabungkan ke main dan cabang rilis dibuat darinya. Rilis tersebut berisi semua perubahan yang digabungkan sejak rilis sebelumnya, bukan hanya integrasi model atau pipeline.

Catatan rilis menyoroti model atau pipeline baru dan juga merangkum perubahan lain yang disertakan dalam rilis tersebut. Rilis patch biasanya hanya digunakan untuk perbaikan pada rilis yang sudah ada.

Diffusers memiliki beberapa permintaan fitur terbuka untuk ketiga komponen - silakan lihat sekilas jika Anda belum tahu komponen spesifik apa yang ingin Anda tambahkan:

• Model atau pipeline
• Scheduler

Sebelum menambahkan salah satu dari tiga komponen, sangat disarankan untuk membaca Panduan Filosofi agar lebih memahami desain dari ketiga komponen tersebut. Harap diperhatikan bahwa kami tidak dapat menggabungkan penambahan model, penjadwal, atau pipeline yang sangat menyimpang dari filosofi desain kami, karena hal itu akan menyebabkan inkonsistensi API. Jika Anda sangat tidak setuju dengan pilihan desain tertentu, silakan buka Isu Umpan Balik agar dapat didiskusikan apakah pola desain/pilihan desain tertentu harus diubah di seluruh pustaka dan apakah kami harus memperbarui filosofi desain kami. Konsistensi di seluruh pustaka sangat penting bagi kami.

Pastikan untuk menambahkan tautan ke kode dasar/paper asli ke PR, dan idealnya juga langsung menghubungi penulis asli di PR tersebut agar mereka dapat mengikuti perkembangan dan berpotensi membantu menjawab pertanyaan.

Jika Anda ragu atau terjebak dalam PR, jangan ragu untuk meninggalkan pesan untuk meminta tinjauan awal atau bantuan.

Disalin dari mekanisme

Fitur unik dan penting yang perlu dipahami saat menambahkan kode pipeline, model, atau scheduler apa pun adalah mekanisme # Copied from. Anda akan melihat ini di seluruh codebase Diffusers, dan alasan kami menggunakannya adalah untuk menjaga codebase agar mudah dipahami dan dipelihara. Menandai kode dengan mekanisme # Copied from memaksa kode yang ditandai menjadi identik dengan kode sumbernya. Hal ini memudahkan pembaruan dan penyebaran perubahan di banyak file setiap kali Anda menjalankan make fix-copies.

Sebagai contoh, pada contoh kode di bawah, StableDiffusionPipelineOutput adalah kode asli dan AltDiffusionPipelineOutput menggunakan mekanisme # Copied from untuk menyalinnya. Satu-satunya perbedaan adalah mengubah prefiks kelas dari Stable menjadi 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.
    """

Untuk mempelajari lebih lanjut, baca bagian ini dari artikel blog ~Jangan~ Ulangi Dirimu*.

Cara menulis isu yang baik

Semakin baik penulisan masalah Anda, semakin besar kemungkinan masalah tersebut akan segera diselesaikan.

1. Pastikan Anda telah menggunakan template yang benar untuk masalah Anda. Anda dapat memilih antara Laporan Bug, Permintaan Fitur, Masukan tentang Desain API, Penambahan model/pipeline/scheduler baru, atau masalah kosong. Pastikan untuk memilih yang benar saat membuka masalah baru. Pertanyaan penggunaan harus diajukan di GitHub Discussions, bukan dalam sebuah masalah.
2. Jadilah spesifik: Berikan judul yang sesuai untuk masalah Anda. Usahakan untuk merumuskan deskripsi masalah Anda sesederhana mungkin. Semakin spesifik Anda saat mengajukan masalah, semakin sedikit waktu yang dibutuhkan untuk memahami dan berpotensi menyelesaikan masalah tersebut. Pastikan untuk membuka satu masalah untuk satu masalah saja, bukan untuk beberapa masalah. Jika Anda menemukan beberapa masalah, cukup buka beberapa masalah. Jika masalah Anda adalah bug, usahakan untuk sespesifik mungkin tentang bug apa yang dimaksud - Anda tidak boleh hanya menulis “Error in diffusers”.
3. Reproducibility: Tidak ada potongan kode yang dapat direproduksi == tidak ada solusi. Jika Anda menemukan bug, maintainer harus dapat mereproduksi bug tersebut. Pastikan Anda menyertakan potongan kode yang dapat disalin-tempel ke interpreter Python untuk mereproduksi masalah tersebut. Pastikan potongan kode Anda berfungsi, artinya tidak ada import yang hilang atau tautan gambar yang hilang, … Masalah Anda harus berisi pesan error dan potongan kode yang dapat disalin-tempel tanpa perubahan apa pun untuk mereproduksi pesan error yang persis sama. Jika masalah Anda menggunakan bobot model lokal atau data lokal yang tidak dapat diakses oleh pembaca, masalah tersebut tidak dapat diselesaikan. Jika Anda tidak dapat membagikan data atau model Anda, cobalah membuat model dummy atau data dummy.
4. Minimalis: Usahakan membantu pembaca memahami masalah secepat mungkin dengan tetap sesingkat mungkin. Hapus semua kode / informasi yang tidak relevan dengan masalah tersebut. Jika Anda menemukan bug, cobalah membuat contoh kode sesederhana mungkin untuk mendemonstrasikan masalah Anda, jangan langsung menumpahkan seluruh alur kerja Anda ke dalam masalah begitu Anda menemukan bug. Misalnya, jika Anda melatih model dan mendapatkan error pada beberapa titik selama pelatihan, Anda harus terlebih dahulu mencoba memahami bagian mana dari kode pelatihan yang bertanggung jawab atas error tersebut dan mencoba mereproduksinya dengan beberapa baris. Usahakan menggunakan data dummy alih-alih dataset lengkap.
5. Konteks: Ceritakan apa yang sedang Anda kerjakan saat menemukan bug atau membutuhkan fitur tersebut, seperti aplikasi yang dibangun di atas Diffusers, proyek penelitian, atau agen yang Anda jalankan untuk mencari bug di dalam pustaka. Satu atau dua kalimat sudah cukup, dan tautan ke proyek sangat dihargai. Kami menerima lebih banyak masalah dan PR daripada yang bisa kami tangani sekaligus, sehingga konteks membantu kami memprioritaskan berdasarkan dampak.
6. Tambahkan tautan. Jika Anda merujuk pada penamaan, metode, atau model tertentu, pastikan untuk menyediakan tautan agar pembaca dapat lebih memahami maksud Anda. Jika Anda merujuk pada PR atau issue tertentu, pastikan untuk menautkannya ke issue Anda. Jangan berasumsi bahwa pembaca tahu apa yang Anda bicarakan. Semakin banyak tautan yang Anda tambahkan ke issue Anda, semakin baik.
7. Formatting. Pastikan Anda memformat issue dengan rapi, yaitu dengan memformat kode ke dalam sintaks kode Python, dan pesan error ke dalam sintaks kode biasa. Lihat dokumentasi format resmi GitHub untuk informasi lebih lanjut.
8. Anggaplah masalah Anda bukan sebagai tiket yang harus diselesaikan, melainkan sebagai entri yang indah dalam ensiklopedia yang ditulis dengan baik. Setiap masalah yang ditambahkan adalah kontribusi terhadap pengetahuan yang tersedia secara publik. Dengan menambahkan masalah yang ditulis dengan rapi, Anda tidak hanya memudahkan para maintainer untuk menyelesaikan masalah Anda, tetapi juga membantu seluruh komunitas untuk lebih memahami aspek tertentu dari pustaka tersebut.

Cara menulis PR yang baik

1. Selalu mulai dari sebuah issue. Temukan issue yang ditangani oleh pull request Anda, atau buat satu jika belum ada, dan beri para maintainer kesempatan untuk merespons sebelum Anda menulis kode. Alur kerja yang paling efektif bagi kami adalah membuka issue, kemudian berdiskusi tentang solusinya, lalu membuat PR berdasarkan diskusi tersebut. Hal ini memungkinkan kami untuk memfokuskan waktu pada issue yang paling berdampak, menyepakati cakupan sebelum kode dibuat, dan menghindari pekerjaan yang duplikat. Sebutkan nomor issue dalam deskripsi PR (misalnya Fixes #1234) agar keduanya terhubung.
2. Jadilah kameleon. Pahami pola desain dan sintaksis yang ada, serta pastikan penambahan kode Anda menyatu dengan mulus ke dalam basis kode yang ada. Permintaan penarikan (pull request) yang menyimpang secara signifikan dari pola desain atau antarmuka pengguna yang ada tidak akan digabungkan (merged).
3. Fokuslah secara tajam. Satu pull request harus menyelesaikan satu masalah dan hanya satu masalah. Pastikan Anda tidak terjebak dalam jebakan “sementara menambahkan ini, perbaiki juga masalah lain”. Meninjau pull request yang menyelesaikan beberapa masalah yang tidak terkait sekaligus jauh lebih sulit.
4. Perbaiki pola, bukan kasus satu kali. Satu masalah dapat melintasi banyak file: jika bug yang sama berulang di seluruh codebase, cari setiap instansinya dan perbaiki semuanya dalam satu PR dengan cakupan yang jelas dan sistematis (misalnya “fix mutable defaults across all schedulers”), bukan satu PR per instans.
5. Judul pull request Anda harus menjadi ringkasan dari kontribusinya. Untuk menunjukkan pekerjaan yang sedang berlangsung, awali judul dengan [WIP]; hal ini menghindari pekerjaan yang duplikat dan memisahkan PR dari yang sudah siap untuk digabungkan.
6. Coba rumuskan dan format teks Anda seperti yang dijelaskan dalam Cara menulis issue yang baik.
7. Tinjau diff Anda sendiri sebelum membuka PR. Bacalah seperti seorang reviewer dan perbaiki apa yang Anda temukan. Kami sangat merekomendasikan untuk menjalankan skill self-review: skill ini menjalankan rubrik yang sama dengan reviewer CI @claude. Siapkan agen Anda seperti yang dijelaskan dalam Coding with AI agents dan ikuti AI-assisted and agentic contributions. Sebutkan dalam deskripsi temuan yang sengaja Anda biarkan apa adanya, agar reviewer tahu bahwa itu adalah keputusan dan bukan kelalaian.
8. Pastikan tes yang ada lulus.
9. Tambahkan tes dengan cakupan tinggi. Tidak ada pengujian kualitas = tidak ada merge.

• Jika Anda menambahkan tes @slow baru, pastikan mereka lulus menggunakan RUN_SLOW=1 python -m pytest tests/test_my_new_model.py. CircleCI tidak menjalankan tes lambat, tetapi GitHub Actions melakukannya setiap malam!

10. Semua metode publik harus memiliki docstring yang informatif dan berfungsi dengan baik dengan markdown. Lihat pipeline_latent_diffusion.py sebagai contoh.
11. Karena repositori yang berkembang pesat, penting untuk memastikan bahwa tidak ada file yang akan membuat repositori menjadi sangat berat yang ditambahkan. Ini mencakup gambar, video, dan file non-teks lainnya. Kami lebih memilih untuk memanfaatkan dataset yang di-hosting di hf.co seperti hf-internal-testing atau huggingface/documentation-images untuk menempatkan file-file tersebut. Jika ini adalah kontribusi eksternal, silakan tambahkan gambar ke PR Anda dan minta anggota Hugging Face untuk memigrasikan gambar Anda ke dataset ini.

Cara membuka PR

Sebelum menulis kode, kami sangat menyarankan Anda untuk mencari melalui PR atau isu yang sudah ada untuk memastikan bahwa tidak ada yang sedang mengerjakan hal yang sama. Jika Anda tidak yakin, selalu menjadi ide yang baik untuk membuka isu untuk mendapatkan beberapa umpan balik.

Anda perlu memiliki kemampuan dasar git untuk dapat berkontribusi pada 🧨 Diffusers. git bukanlah alat yang paling mudah digunakan, tetapi memiliki manual yang sangat lengkap. Ketik git --help di shell dan nikmati. Jika Anda lebih suka buku, Pro Git adalah referensi yang sangat baik.

Ikuti langkah-langkah berikut untuk mulai berkontribusi (versi Python yang didukung):

1. Fork repository dengan mengklik tombol ‘Fork’ di halaman repository. Hal ini membuat salinan kode di bawah akun GitHub Anda.

2. Klon fork Anda ke disk lokal, dan tambahkan repositori dasar sebagai remote:

   Disalin

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

3. Buat cabang baru untuk menyimpan perubahan pengembangan Anda:

   Disalin

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

Jangan bekerja di cabang main.

4. Siapkan lingkungan pengembangan dengan menjalankan perintah berikut dalam lingkungan virtual:

   Disalin

   $ pip install -e ".[dev]"

Jika Anda sudah mengkloning repo, Anda mungkin perlu git pull untuk mendapatkan perubahan terbaru di library.

5. Kembangkan fitur pada cabang Anda.

Saat Anda mengerjakan fitur-fitur tersebut, pastikan bahwa suite test lolos. Anda harus menjalankan test yang terdampak oleh perubahan Anda seperti ini:

$ pytest tests/<TEST_TO_RUN>.py

Sebelum Anda menjalankan pengujian, pastikan Anda menginstal dependensi yang diperlukan untuk pengujian. Anda dapat melakukannya dengan perintah ini:

$ pip install -e ".[test]"

Anda juga dapat menjalankan seluruh suite pengujian dengan perintah berikut, tetapi sekarang dibutuhkan mesin yang bertenaga untuk menghasilkan hasil dalam waktu yang wajar karena Diffusers telah berkembang pesat. Berikut adalah perintahnya:

$ make test

🧨 Diffusers bergantung pada black dan isort untuk memformat kode sumbernya secara konsisten. Setelah Anda membuat perubahan, terapkan koreksi gaya otomatis dan verifikasi kode yang tidak dapat diotomatisasi sekaligus dengan:

$ make style

🧨 Diffusers juga menggunakan ruff dan beberapa skrip kustom untuk memeriksa kesalahan penulisan kode. Pengendalian kualitas dijalankan di CI, namun Anda juga dapat menjalankan pemeriksaan yang sama dengan:

$ make quality

Setelah Anda puas dengan perubahan Anda, tambahkan file yang diubah menggunakan git add dan buat commit dengan git commit untuk mencatat perubahan Anda secara lokal:

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

Sebaiknya Anda menyinkronkan salinan kode Anda dengan repositori asli secara berkala. Dengan cara ini, Anda dapat dengan cepat menyesuaikan diri terhadap perubahan:

$ git pull upstream main

Dorong perubahan ke akun Anda menggunakan:

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

6. Setelah Anda merasa puas, buka halaman web fork Anda di GitHub. Klik ‘Pull request’ untuk mengirim perubahan Anda ke maintainer proyek untuk ditinjau.

7. Tidak masalah jika maintainer meminta Anda melakukan perubahan. Hal ini juga terjadi pada kontributor inti! Agar semua orang dapat melihat perubahan dalam Pull request, kerjakan di branch lokal Anda dan push perubahan tersebut ke fork Anda. Perubahan tersebut akan secara otomatis muncul di pull request.

Uji

Suite pengujian yang luas disertakan untuk menguji perilaku pustaka dan beberapa contoh. Pengujian pustaka dapat ditemukan di folder tests.

Kami menyukai pytest dan pytest-xdist karena lebih cepat. Dari root repository, berikut cara menjalankan tes dengan pytest untuk library:

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

Faktanya, itulah cara make test diimplementasikan!

Anda dapat menentukan set pengujian yang lebih kecil untuk menguji hanya fitur yang sedang Anda kerjakan.

Secara default, tes lambat dilewati. Atur variabel lingkungan RUN_SLOW ke yes untuk menjalankannya. Hal ini akan mengunduh model berukuran beberapa gigabyte — pastikan Anda memiliki ruang disk yang cukup dan koneksi Internet yang baik, atau kesabaran yang banyak!

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

unittest sepenuhnya didukung, berikut cara menjalankan tes dengannya:

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

Sinkronisasi main yang di-fork dengan main upstream (HuggingFace)

Untuk menghindari pinging ke repositori upstream yang menambahkan catatan referensi ke setiap PR upstream dan mengirim notifikasi yang tidak perlu ke pengembang yang terlibat dalam PR tersebut, saat menyinkronkan cabang utama dari repositori yang di-fork, silakan ikuti langkah-langkah berikut:

1. Jika memungkinkan, hindari sinkronisasi dengan upstream menggunakan cabang dan PR pada repositori fork. Sebaliknya, gabungkan langsung ke main pada repositori fork.
2. Jika PR benar-benar diperlukan, gunakan langkah-langkah berikut setelah memeriksa out cabang Anda:

$ 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

Gaya penulisan

Untuk string dokumentasi, 🧨 Diffusers mengikuti gaya Google.

Coding dengan agen AI

Repositori menyimpan konfigurasi agen AI di .ai/, yang juga diterbitkan sebagai plugin agen sehingga keterampilan tugas on-demand dapat diinstal dalam satu langkah.

• Hanya-baca bagi kontributor — .ai/ dikelola oleh maintainer inti. Jangan mengedit file di bawah .ai/ (atau symlink AGENTS.md / CLAUDE.md di level root, atau .agents/skills / .claude/skills yang terpasang) dalam PR Anda. Jika Anda menemukan sesuatu yang hilang atau salah, buka issue atau tandai di PR dan seorang maintainer akan memperbaruinya.
• Guidelines — .ai/AGENTS.md dimuat ke setiap sesi agen melalui symlink AGENTS.md / CLAUDE.md di root; panduan referensi di bawah .ai/references/ dibaca sesuai kebutuhan saat tautan diikuti:
  • .ai/AGENTS.md — pedoman penulisan kode tingkat atas
  • .ai/references/models.md — pola perhatian, aturan implementasi model, konvensi umum
  • .ai/references/pipelines.md — konvensi pipeline
  • .ai/references/modular.md — konvensi pipeline modular dan daftar periksa konversi
  • .ai/references/testing.md — lapisan pengujian yang diperlukan, mixin penguji, aturan komponen dummy
  • .ai/references/review-rules.md — apa yang dicari oleh para reviewer
• Skills (di bawah .ai/skills/, dimuat sesuai kebutuhan untuk tugas tertentu):
  • model-integration — menambahkan model atau pipeline baru ke diffusers secara end-to-end (struktur file, checklist integrasi, tata letak pengujian, konversi bobot)
  • self-review — tinjau perubahan Anda terhadap aturan proyek sebelum membuka PR
  • diffusers-cli — menjalankan pipeline dan memeriksa skema dari terminal
  • custom-blocks — mengemas subclass ModularPipelineBlocks untuk Hub

Terlepas dari jalur yang Anda pilih, minta agen Anda untuk mengonfigurasi ulang setup-nya sendiri sebelum Anda memulai — python utils/check_ai.py memeriksa bahwa panduan dan skill konsisten, dan diffusers-cli skills list menampilkan skill apa yang benar-benar dimilikinya.

Kontribusi yang dibantu AI dan agen

AI agents dipersilakan untuk berkontribusi pada Diffusers. Kami mendorong Anda untuk mengatur agen Anda dengan panduan agen Diffusers dan menggunakan keterampilan spesifik tugas yang relevan, seperti model-integration dan self-review. Instal plugin (atau keterampilan individual) seperti yang dijelaskan di atas, lalu ikuti panduan untuk menentukan cakupan, mengimplementasikan, menguji, dan meninjau kontribusi Anda. Anda tetap bertanggung jawab untuk memahami, menguji, dan memelihara perubahan dalam PR Anda.

Kontribusi yang dibantu AI disambut baik, tetapi harus dikoordinasikan, dibatasi cakupannya, dan diverifikasi agar beban review tetap terkendali. PR yang tidak mengikuti pedoman ini dapat ditutup tanpa review terperinci.

• Selesaikan koordinasi sebelum membuka PR. Cari atau buka issue, tinjau PR serupa (yang masih terbuka dan yang baru saja ditutup), dan tunggu pengakuan eksplisit dari maintainer pada issue tersebut sebelum membuka PR. Hal ini memberi kami kesempatan untuk membahas cakupan, menghindari pekerjaan yang tumpang tindih, dan memastikan pendekatan yang digunakan.
• Perbaiki pola, bukan kasus satu kali. Jika Anda menemukan masalah yang berulang, cari instans serupa di codebase dan buka satu issue dengan cakupan yang jelas dan sistematis (misalnya “perbaiki default mutable di semua scheduler”) alih-alih banyak issue atau PR untuk instans individual.
• Ulasan mandiri sebelum membuka. Jalankan skill self-review — skill ini meninjau diff Anda terhadap .ai/references/review-rules.md, rubrik yang sama yang digunakan oleh peninjau CI @claude — dan tangani apa yang dilaporkan — ini adalah alat bantu, bukan otoritatif, dan bisa salah. Fokus pada masalah pemblokir yang masuk akal bagi Anda, dan bersihkan kode mati/tidak terpakai sebanyak mungkin. Jika Anda tidak setuju dengan sebuah saran, tidak masalah untuk membiarkannya agar peninjau dapat mendiskusikannya setelah PR dibuka — catatan yang Anda bagikan (lihat di bawah) memberi tahu peninjau bahwa itu adalah keputusan yang disengaja.
• Bagikan catatan tinjauan mandiri Anda. Silakan unggah laporan tinjauan mandiri final — ronde yang mencerminkan diff yang Anda kirimkan — di PR, baik di deskripsi maupun sebagai komentar, termasuk temuan yang sengaja tidak Anda perbaiki beserta alasannya. Hal ini membantu peninjau melihat apa yang sudah diperiksa dan keputusan mana yang disengaja, serta biasanya menghemat beberapa putaran diskusi bolak-balik.
• Jaga komunikasi PR Anda tetap ringkas. Segala hal yang dibaca reviewer di PR Anda — deskripsi, pesan commit, komentar dan balasan, komentar kode — harus mudah dipahami manusia. Jika agen yang menyusunnya, jangan hanya memindainya. Bacalah, dan minta agen untuk merevisinya hingga menghasilkan sesuatu yang masuk akal dan ringkas yang akan Anda tulis sendiri. Anda adalah penulis dari segala hal yang Anda unggah.
• Include in the PR description:
  • tautan koordinasi ke masalah atau diskusi tempat maintainer mengakui pekerjaan tersebut.
  • Perintah pengujian yang Anda jalankan dan hasilnya (tempelkan output yang relevan, bukan hanya “tests pass”).
  • Catatan tinjauan mandiri Anda (atau tautan ke komentar PR yang memuatnya), seperti yang dijelaskan di atas.

Jika Anda adalah penulis model atau bagian dari tim yang secara resmi memelihara sebuah model, kami mendorong Anda untuk menggunakan agen untuk integrasi model baru. Ikuti pengaturan yang direkomendasikan dari repositori dan gunakan skill model-integration. Koordinasikan cakupan dengan para maintainer sebelum membuka PR — lihat Menambahkan pipeline, model, scheduler.