Hugging Face's logo

Diffusers documentation

Diffusers'a nasıl katkıda bulunulur 🧨

You are viewing main version, which requires installation from source. If you'd like regular pip install, checkout the latest stable version (v0.42.1).
Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Diffusers'a nasıl katkıda bulunulur 🧨

Bir yapay zeka ajanı kullanarak katkıda bulunuyorsanız, beklentilerimizi ve yönergelerimizi içeren Yapay zeka destekli ve ajan tabanlı katkılar bölümünü okuduğunuzdan emin olun.

Açık kaynak topluluğundan gelen katkıları ❤️ çok seviyoruz! Herkes davetlidir ve kodun ötesinde her türlü katılım –soru yanıtlama, başkalarına yardım etme, iletişim kurma ve dokümantasyonu iyileştirme gibi– topluluk için son derece değerli ve takdir edilmektedir. Bu yüzden cesaret edin ve bu işe gönül veriyorsanız topluluğa katılın!

Herkese, herkese açık Discord kanalımızda 👋 diyerek başlaması önerilir. Difüzyon modellerindeki son trendleri tartışır, sorular sorar, kişisel projelerimizi sergiler, katkıları konusunda birbirimize yardımcı olur veya sadece takılırız ☕. Join us on Discord

Katkıda bulunmak için hangi yolu seçerseniz seçin, açık, misafirperver ve nazik bir topluluğun parçası olmayı hedefliyoruz. Lütfen davranış kurallarımızı okuyun ve etkileşimleriniz sırasında bunlara saygı göstermeye özen gösterin. Ayrıca, projemizi yönlendiren etik ilkelerle de tanışmanızı önerir ve şeffaflık ve sorumluluk ilkelerine uymanızı rica ederiz.

Topluluktan gelen geri bildirimleri son derece değerli buluyoruz; bu nedenle, kütüphanenin iyileştirilmesine yardımcı olabilecek değerli bir geri bildiriminiz olduğunu düşünüyorsanız sesinizi çıkarmaktan çekinmeyin - her mesaj, yorum, sorun ve çekme isteği (PR) okunur ve değerlendirilir.

Genel Bakış

Soruları yanıtlamaktan çekirdek kütüphaneye yeni difüzyon modelleri eklemeye kadar birçok farklı şekilde katkıda bulunabilirsiniz.

Aşağıda, artan zaman yükümlülüğüne göre sıralanmış, katkıda bulunmanın farklı yollarına bir genel bakış sunuyoruz. Bunların tümü topluluk için değerlidir.

Daha önce belirtildiği gibi, tüm katkılar topluluk için değerlidir. Aşağıda, her bir katkıyı biraz daha ayrıntılı olarak açıklayacağız.

4'ten 10'a kadar olan katkılar için, Hub üzerinde barındırılan 6 hariç, bir PR açmanız gerekecektir. Bunun nasıl yapılacağı Opening a pull request başlığında ayrıntılı olarak açıklanmıştır.

1. GitHub Tartışmaları'nda veya Discord'da soru sormak ve yanıtlamak

Diffusers kütüphanesiyle ilgili herhangi bir soru veya yorum GitHub Tartışmaları veya Discord üzerinden sorulabilir. Bu tür sorular ve yorumlar şunları içerir (ancak bunlarla sınırlı değildir):

  • Bilgi paylaşma amacıyla eğitim veya çıkarım deneylerinin raporlanması
  • Kişisel projelerin sunumu
  • Resmi olmayan eğitim örneklerine yönelik sorular
  • Proje önerileri
  • Genel geri bildirim
  • Makale özetleri
  • Diffusers kütüphanesinin üzerine inşa edilen kişisel projelerde yardım istemek
  • Genel sorular
  • Difüzyon modellerine ilişkin etik sorular
  • …

GitHub Tartışmaları'nda veya Discord'da sorulan her soru, topluluğun bilgiyi kamuya açık şekilde paylaşmasını aktif olarak teşvik eder ve gelecekte aynı soruyu soran bir başlangıç seviyesindeki kullanıcıya çok yardımcı olabilir. Lütfen aklınıza takılan her soruyu sormaktan çekinmeyin. Aynı ruhla, bu tür soruları yanıtlayarak topluluğa çok büyük bir katkıda bulunuyorsunuz; çünkü bu sayede herkesin öğrenmesi için bilgiyi kamuya açık şekilde belgelemiş olursunuz.

Lütfen bir soru sormaya veya yanıtlamaya ne kadar çok emek harcarsanız, kamuya açık olarak belgelenen bilginin kalitesinin de o kadar yüksek olacağını aklınızda bulundurun. Aynı şekilde, iyi kurgulanmış ve iyi yanıtlanmış sorular herkese erişilebilir yüksek kaliteli bir bilgi veritabanı oluştururken, kötü kurgulanmış sorular veya yanıtlar kamuya açık bilgi veritabanının genel kalitesini düşürür. Kısacası, yüksek kaliteli bir soru veya yanıt kesin, kısa, ilgili, anlaşılması kolay, erişilebilir ve iyi biçimlendirilmiş/iyi kurgulanmış olmalıdır. Daha fazla bilgi için Nasıl iyi bir issue yazılır bölümüne göz atmanızı öneririz.

Kanallar hakkında NOT: GitHub Discussions arama motorları tarafından indekslenir ve her thread'e bağlantı verilebilir, bu nedenle orada paylaşılan sorular ve yanıtlar, aynı sorunu yaşayan sonraki kişi için bulunabilir kalmaya devam eder. Buna karşılık, Discord hızlı gidip gelmeli iletişimi teşvik eden sohbet benzeri bir formata sahiptir. Sorunuza Discord'da yanıt almanız muhtemelen daha az zaman alacak olsa da, sorunuz zamanla görünmez hale gelir ve bir süre önce paylaşılan bilgileri bulmak çok daha zordur. Bu nedenle, kalıcı olması amaçlanan soru ve yanıtlar için GitHub Discussions'ı öneririz. Discord'daki bir sohbet ilginç bir sonuca ulaşırsa, gelecekteki okuyucuların bulabilmesi için sonucu bir tartışma olarak paylaşın.

2. GitHub sorunları sekmesinde yeni sorunlar açma

🧨 Diffusers kütüphanesi, karşılaştıkları sorunları bize bildiren kullanıcılar sayesinde sağlam ve güvenilirdir. Bu nedenle bir sorun bildirdiğiniz için teşekkür ederiz.

Unutmayın, GitHub sorunları, Diffusers kütüphanesiyle doğrudan ilgili teknik sorular, hata bildirimleri, özellik talepleri veya kütüphane tasarımıyla ilgili geri bildirimler için ayrılmıştır.

In a nutshell, this means that everything that is not related to the code of the Diffusers library (including the documentation) should not be asked as an issue, but rather on GitHub Discussions or Discord.

Yeni bir sorun açarken aşağıdaki yönergeleri göz önünde bulundurun:

  • Sorunuzun daha önce sorulup sorulmadığını aradığınızdan emin olun (GitHub'da Issues altında arama çubuğunu kullanın).
  • Lütfen asla yeni bir sorunu başka (ilgili) bir sorun üzerinde bildirmeyin. Başka bir sorunla yüksek derecede ilgiliyse, yine de yeni bir sorun açın ve ilgili soruna bağlantı verin.
  • Sorunuzun İngilizce olarak yazıldığından emin olun.
  • Sorunun en yeni Diffusers sürümüne güncelleyerek çözülebileceğini kontrol edin. Sorununuzun paylaşımından önce, python -c "import diffusers; print(diffusers.__version__)" komutunun en son Diffusers sürümünden yüksek veya eşit olduğundan emin olun.
  • Yeni bir sorun açmak için harcadığınız çabanın artmasıyla, alacağınız yanıtın kalitesinin ve Diffusers sorunlarının genel kalitesinin de artacağını unutmayın.

Yeni sorunlar genellikle şunları içerir.

2.1. Yeniden üretilebilir, minimal hata raporları

Bir hata raporu her zaman yeniden üretilebilir bir kod parçası içermeli ve mümkün olduğunca minimal ve öz olmalıdır. Bu, daha ayrıntılı olarak şunu ifade eder:

  • Hatalı davranışı mümkün olduğunca daraltın, tüm kod dosyanızı olduğu gibi yapıştırmayın.
  • Kodunuzu biçimlendirin.
  • Diffusers'a bağımlı olanlar hariç, harici kütüphaneler dahil etmeyin.
  • Her zaman ortamınızla ilgili gerekli tüm bilgileri sağlayın; bunun için kabuğunuzda diffusers-cli env komutunu çalıştırabilir ve ekranda görünen bilgileri soruna kopyalayıp yapıştırabilirsiniz.
  • Sorunu açıklayın. Okuyucu sorunun ne olduğunu ve neden bir sorun olduğunu bilmiyorsa, onu çözemeyecektir.
  • Her zaman okuyucunun sorununuzu olabildiğince az eforla yeniden üretebileceğinden emin olun. Kod parçanız eksik kütüphaneler veya tanımsız değişkenler nedeniyle çalıştırılamıyorsa, okuyucu size yardımcı olamaz. Yeniden üretilebilir kod parçanızın olabildiğince minimal olduğundan ve basit bir Python kabuğuna kopyala-yapıştır edilebildiğinden emin olun.
  • Sorununuzun yeniden oluşturulması için bir model ve/veya veri seti gerekiyorsa, okuyucunun bu modele veya veri setine erişebildiğinden emin olun. Modelinizi veya veri setinizi kolayca indirilebilir hale getirmek için her zaman Hub üzerinden yükleyebilirsiniz. Sorununuzun yeniden oluşturulmasını olabildiğince zahmetsiz kılmak için modelinizi ve veri setinizi mümkün olan en küçük boyutta tutmaya çalışın.

Daha fazla bilgi için Nasıl iyi bir sorun yazılır bölümüne göz atın.

Bir hata raporu açmak için buraya tıklayabilirsiniz.

2.2. Özellik istekleri

Dünya çapında bir özellik isteği aşağıdaki noktaları ele alır:

  1. Önce motivasyon:
  • Kütüphaneyle ilgili bir sorun/rahatsızlıkla ilgili mi? Öyleyse lütfen nedenini açıklayın. Sorunu gösteren bir kod parçası paylaşmak en iyisidir.
  • Bir proje için ihtiyaç duyacağınız bir şeyle ilgili mi? Bunu duymaktan memnuniyet duyarız!
  • Üzerinde çalıştığınız ve topluluğa fayda sağlayabileceğini düşündüğünüz bir şey mi? Harika! Size ne sorunu çözdüğünü anlatın.
  1. Özelliği açıklayan tam bir paragraf yazın;
  2. Gelecekteki kullanımını gösteren bir kod parçası sağlayın;
  3. Eğer bu bir makaleyle ilgiliyse, lütfen bir bağlantı ekleyin;
  4. Yararlı olabileceğini düşündüğünüz ek bilgileri (çizimler, ekran görüntüleri vb.) ekleyin.

Bir özellik isteği açmak için buraya tıklayabilirsiniz.

2.3 Geri bildirim

Kütüphane tasarımı hakkındaki geri bildirimler ve tasarımın neden iyi veya iyi olmadığına dair açıklamalar, çekirdek bakım sorumlularının kullanıcı dostu bir kütüphane oluşturmasında onlara büyük ölçüde yardımcı olur. Mevcut tasarım felsefesinin arkasındaki felsefeyi anlamak için lütfen buraya göz atın. Belirli bir tasarım seçiminin mevcut tasarım felsefesiyle uyumlu olmadığını düşünüyorsanız, nedenini ve nasıl değiştirilmesi gerektiğini lütfen açıklayın. Belirli bir tasarım seçimi, kullanım senaryolarını kısıtladığı için tasarım felsefesine fazla bağlıysa, nedenini ve nasıl değiştirilmesi gerektiğini açıklayın. Belirli bir tasarım seçimi sizin için çok faydalıysa, lütfen bir not bırakın; bu, gelecekteki tasarım kararları için harika bir geri bildirimdir.

Geri bildirimle ilgili bir sorun burada açabilirsiniz.

2.4 Teknik sorular

Teknik sorular, kütüphanenin belirli kodunun neden belirli bir şekilde yazıldığına veya kodun belirli bir bölümünün ne işe yaradığına dairdir. Lütfen ilgili koda bağlantı verin ve bu kod bölümünün neden anlaşılması güç olduğunu açıklayan ayrıntıları belirtin.

Teknik bir soruyla ilgili bir sorun burada açabilirsiniz.

2.5 Yeni bir model, zamanlayıcı veya hattı ekleme önerisi

Diffusion model topluluğu, Diffusers kütüphanesinde görmek istediğiniz yeni bir model, pipeline veya scheduler yayınladıysa, lütfen aşağıdaki bilgileri sağlayın:

  • Diffüzyon hattının, modelinin veya zamanlayıcısının kısa tanımı ve makaleye veya halka açık sürüme bağlantı.
  • Açık kaynaklı uygulaması/uygulamalarından herhangi birine bağlantı.
  • Eğer mevcutlarsa, model ağırlıklarına bağlantı.

Ayrıca, bulabiliyorsanız, bileşenin (model, zamanlayıcı, boru hattı vb.) orijinal yazarını GitHub kullanıcı adıyla etiketlemeyi unutmayın.

Modeli Diffusers'a kendiniz eklemek istiyorsanız, Hub'da bir pipeline veya model yayımlama ve Pipeline, model ve scheduler ekleme konularına bakın.

Bir model/pipeline/scheduler için talep oluşturmak için buraya tıklayabilirsiniz.

3. GitHub sorunları sekmesindeki sorunlara yanıt verme

GitHub'daki sorunlara yanıt vermek Diffusers hakkında bazı teknik bilgi gerektirebilir, ancak yanıtınızın %100 doğru olduğundan emin olmasanız bile herkesi denemeye teşvik ediyoruz. Bir soruna yüksek kaliteli bir yanıt vermek için bazı ipuçları:

  • Mümkün olduğunca kısa ve minimal olun.
  • Konudan sapmayın. Soruna verilen yanıt, yalnızca ve yalnızca o soruyla ilgili olmalıdır.
  • İddianızı kanıtlayan veya destekleyen kod, makale veya diğer kaynaklara bağlantılar ekleyin.
  • Kodla yanıt verin. Sorunun cevabı basit bir kod parçasıysa veya sorunun nasıl çözülebileceğini gösteriyorsa, lütfen tamamen yeniden üretilebilir bir kod parçası sağlayın.

Ayrıca, birçok sorun genellikle konuyla alakasız, diğer sorunların tekrarı veya ilgisiz olma eğilimindedir. Bu tür sorunlara yanıt vermeniz, sorunun yazarını daha kesin olmaya teşvik etmeniz, tekrarlanan soruna bağlantı vermeniz veya onları GitHub Discussions veya Discord yönlendirmeniz, bakımcılar için büyük bir kolaylık sağlar.

Yayımlanan hata raporunun doğru olduğunu ve kaynak kodda bir düzeltme gerektirdiğini doğruladıysanız, lütfen sonraki bölümlere göz atın.

6 hariç tüm katkılar için bir PR açmanız gerekir. Opening a pull request bölümü bunu nasıl yapacağınızı açıklar.

4. “Good first issue” düzeltme

İlk iyi sorunlar, İlk iyi sorun etiketiyle işaretlenir. Genellikle, sorun, çözümü daha kolay hale getirmek için olası bir çözümün nasıl görünmesi gerektiğini zaten açıklar. Sorun kapatılmamışsa ve bu sorunu çözmeyi denemek istiyorsanız, sadece “Bu sorunu denemek istiyorum.” mesajını bırakabilirsiniz. Genellikle üç senaryo vardır:

  • a.) Sorun açıklaması zaten bir düzeltme öneriyor. Bu durumda ve çözüm size mantıklı geliyorsa, düzeltmek için bir PR veya taslak PR açabilirsiniz.
  • b.) Sorun açıklaması bir düzeltme önermez. Bu durumda, soruna bir yorum olarak kendi düzeltmenizi önerin. Yaklaşımı açıklayan birkaç cümle yeterlidir. Bir PR açmadan önce Diffusers ekibinden birinin bunu onaylamasını bekleyin.
  • c.) Sorunu düzeltmek için zaten açık bir PR var, ancak sorun henüz kapatılmamış. PR bayatlamışsa, basitçe yeni bir PR açabilir ve bayatlamış PR'a bağlantı verebilirsiniz. Sorunu düzeltmek isteyen orijinal katkıda bulunan kişi artık devam etmek için zaman bulamadığında PR'lar sık sık bayatlar. Bu, açık kaynak dünyasında sıkça görülür ve çok normaldir. Bu durumda, topluluk mevcut PR'ın bilgisinden yararlanarak konuya yeniden el atmanızdan çok memnun olacaktır. Zaten bir PR varsa ve aktifse, önerilerde bulunarak, PR'ı inceleyerek veya PR'a katkıda bulunup bulunamayacağınızı sorarak yazarına yardımcı olabilirsiniz.

5. Dokümantasyona katkıda bulunun

İyi bir kütüphanenin her zaman iyi bir dokümantasyonu vardır! Resmi dokümantasyon, kütüphanenin yeni kullanıcıları için genellikle ilk temas noktalarından biridir ve bu nedenle dokümantasyona katkıda bulunmak son derece değerli bir katkıdır.

Kütüphaneye katkıda bulunmanın birçok biçimi olabilir:

  • Yazım veya dilbilgisi hatalarını düzeltme.
  • Docstring'in hatalı biçimlendirmesini düzeltin. Resmi belgelerin tuhaf göründüğünü veya bir bağlantının bozuk olduğunu fark ederseniz, bunu düzeltmek için biraz zaman ayırmanızdan çok memnun oluruz.
  • Bir docstring girdi veya çıktı tensörünün şeklini veya boyutlarını düzeltin.
  • Anlaşılmaz veya hatalı olan belgeleri netleştirin.
  • Güncel olmayan kod örneklerini güncelleyin.
  • Belgeleri başka bir dile çevirme.

resmi Diffusers doküman sayfasında görüntülenen her şey resmi dokümantasyonun bir parçasıdır ve ilgili dokümantasyon kaynağında düzeltilebilir veya ayarlanabilir.

Belgelerdeki değişikliklerin yerel olarak nasıl doğrulanacağına dair bu sayfaya göz atın.

6. Hub'da bir pipeline veya model yayınlayın

Modular Diffusers ile bir pipeline, herhangi bir Hub deposunda uzak kod olarak barındırılabilir. Herkes, Diffusers sürümünü beklemeden from_pretrained(..., trust_remote_code=True) ile yükleyebilir. Yeni bir pipeline veya model getiren bir topluluk katkıcısıysanız, buradan başlayın. Bir pipeline yayınlamak için özel bloklara, bir model yayınlamak için özel modellere bakın.

Eşleşen model request altında bize bildirin (yoksa bir tane açın): uygulamanız hakkında geri bildirim veriyor ve beğendiklerimizi Community Modular Diffusers Blocks koleksiyonumuzda öne çıkarıyoruz. Ardından modelin kütüphanede nasıl destekleneceğine karar veriyoruz: sürümünüzü upstream edebilir, yazarlarla resmi bir sürüm üzerinde çalışabilir veya insanları doğrudan sürümünüze yönlendirebiliriz. Süreç boyunca karşılaştığınız zorlukları da bize bildirin: kafa karıştırıcı API'ler, eksik dokümantasyon, hatalar. Bu geri bildirim, pipeline kadar bizim için değerlidir.

7. Eğitim örneklerine katkıda bulunun

Diffusers örnekleri, examples dizininde yer alan eğitim betikleri koleksiyonudur.

İki tür eğitim örneğini destekliyoruz:

  • Resmî eğitim örnekleri
  • Araştırma eğitim örnekleri

Araştırma eğitim örnekleri examples/research_projects konumunda yer alırken resmi eğitim örnekleri, research_projects ve community klasörleri hariç olmak üzere examples altındaki tüm klasörleri içerir. Resmi eğitim örnekleri Diffusers’ın ana bakımcıları tarafından, araştırma eğitim örnekleri ise topluluk tarafından sürdürülmektedir. Kütüphanenin Hub üzerinde küçük bir resmi ve topluluk pipeline setini canlı tutmasının nedeni de budur: difüzyon modelleri için olası tüm eğitim yöntemlerini ana bakımcıların sürdürmesi mümkün değildir. Diffusers ana bakımcıları ve topluluk, belirli bir eğitim paradigmasını çok deneysel veya yeterince popüler bulmazsa, ilgili eğitim kodu research_projects klasörüne konmalı ve yazar tarafından sürdürülmelidir.

Hem resmi eğitim hem de araştırma örnekleri, bir veya birden fazla eğitim betiği, requirements.txt dosyası ve README.md dosyası içeren bir dizinden oluşur. Kullanıcının eğitim örneklerinden yararlanabilmesi için depoyu klonlaması gerekir:

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

ve eğitim için gerekli tüm ek bağımlılıkları yüklemek için:

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

Dolayısıyla bir örnek eklerken, requirements.txt dosyası, örnek eğitim betiğinin çalıştırılabilmesi için gerekli tüm pip bağımlılıklarını tanımlamalıdır. Örneğin, DreamBooth requirements.txt dosyasına bakabilirsiniz.

Diffusers kütüphanesinin eğitim örnekleri aşağıdaki felsefeye uymalıdır:

  • Örnekleri çalıştırmak için gerekli tüm kod, tek bir Python dosyasında bulunmalıdır.
  • Örnek, python <your-example>.py --args komutuyla komut satırından çalıştırılabilmelidir.
  • Örnekler basit tutulmalı ve Diffusers'ın eğitim için nasıl kullanılacağına dair bir örnek niteliği taşımalıdır. Örnek betiklerinin amacı, son derece özel mantık eklemeksizin bilinen eğitim şemalarını yeniden üretmek olup en ileri düzeyde difüzyon modelleri oluşturmaktan uzaktır. Bu noktanın bir yan ürünü olarak örneklerimiz, iyi eğitim materyalleri olarak da hizmet etmeye çalışır.

Örnek katkıda bulunmak için, örneklerin nasıl görünmesi gerektiğine dair bir fikir edinmek amacıyla dreambooth gibi mevcut örnekleri incelemeniz şiddetle tavsiye edilir. Katkıda bulunanların, Diffusers ile sıkı bir şekilde entegre olduğu için Accelerate kütüphanesinden faydalanmasını kesinlikle öneririz. Bir örnek betiği çalışmaya başladığında, örneğin tam olarak nasıl kullanılacağını açıklayan kapsamlı bir README.md dosyası eklediğinizden emin olun. Bu README şunları içermelidir:

  • Burada gösterildiği gibi örnek betiği çalıştırmak için örnek bir komut burada.
  • Kullanıcının ne bekleyebileceğini gösteren bazı eğitim sonuçlarına (günlükler, modeller vb.) buradaki bağlantı.
  • Resmî olmayan/araştırma amaçlı bir eğitim örneği ekliyorsanız, lütfen unutmayın ki bu eğitim örneğini sizin sürdürdüğünüzü belirten bir cümle eklemeniz gerekir; git kullanıcı adınız burada gösterildiği gibi yer almalıdır.

Resmi eğitim örneklerine katkıda bulunuyorsanız, examples/dreambooth/test_dreambooth.py gibi bir test dosyasını ilgili klasöre eklemeyi de unutmayın. Bu, resmi olmayan eğitim örnekleri için gerekli değildir.

8. “İyi ikinci sorun”u düzeltme

İyi ikinci sorunlar, İyi ikinci sorun etiketiyle işaretlenir. Genellikle İyi ilk sorunlardan çözümü daha karmaşıktır, açıklama düzeltme konusunda daha az yönlendirme sunar ve kütüphanenin makul düzeyde anlaşılmasını gerektirir.

İyi bir ikinci sorunu ele almakla ilgileniyorsanız, soruya ilişkin görüşünüzü ve aklınızdaki yaklaşımı birkaç cümleyle bir yorum olarak paylaşın ve PR açmadan önce bir bakımcıdan onay alın. Sorun için zaten bir PR açılmışsa ancak birleştirilmediyse, yeni bir şey önermeden önce nedenini anlamak için inceleyin.

9. Diffusers MVP sorunu üstlenmek

Diffusers MVP program, en çok yardıma ihtiyaç duyduğumuz sorunları listeler. Bunlar Good second issue'lar gibi çalışır ancak daha zordur ve daha fazla zaman alır; program, bu sorunları üstlenen katkıda bulunanları ödüllendirir. PR açmadan önce yaklaşımınızı bir yorum olarak paylaşın ve bir bakımcıdan onay alın. Programın ayrıca bir ideas track bölümü vardır: Diffusers'ın etkisini artıracak tek bir fikri, birkaç cümleyle ve uygulama detayları olmadan bize iletin.

10. Boru hatları, modeller ve zamanlayıcılar ekleme

Eğer modelin yazarıysanız, entegrasyonu sizinle koordine edebilmemiz için lütfen bizimle iletişime geçin: bir özellik isteği açın veya zaten açık bir istek varsa yorum bırakın.

Bir topluluk katkıcısıysanız, önce bir Hub deposuyla başlayın, Hub'da bir pipeline veya model yayımlama bölümüne bakın ve upstream etmeye ilgi duyduğunuzu ilgili özellik isteğinin altında bize bildirin.

Pipelines, modeller ve zamanlayıcılar, Diffusers kütüphanesinin en önemli parçalarıdır. Son teknoloji difüzyon teknolojilerine kolay erişim sağlarlar ve bu sayede topluluğun güçlü üretken yapay zekâ uygulamaları oluşturmasına olanak tanır.

Yeni bir model, pipeline veya scheduler ekleyerek, Diffusers'a dayanan herhangi bir kullanıcı arayüzü için yeni ve güçlü bir kullanım senaryosu etkinleştirebilir; bu, tüm üretken yapay zeka ekosistemi için büyük bir değer taşıyabilir.

Yeni model veya pipeline desteği yayınlandığında

Bir sürüme yeni bir model veya hattın dahil edilmesi, entegrasyonu Diffusers ekibiyle önceden koordine etmeniz durumunda mümkündür. Bize Diffusers deposunda bir sorun (issue) açarak veya [email protected] adresine e-posta göndererek ulaşabilirsiniz.

Bir model veya pipeline çekme isteği birleştirildiğinde bir sürüm otomatik olarak yapılmaz. Bir sürüm öncesinde, bakımcılar önce entegrasyonun tamamlandığını ve sürüm testlerinin geçtiğini kontrol eder.

Yeni model veya pipeline desteği genellikle bir sonraki küçük sürüme eklenir. Entegrasyon main dalına birleştirilir ve sürüm dalı bu daldan oluşturulur. Sürüm, yalnızca model veya pipeline entegrasyonu değil, önceki sürümden bu yana birleştirilen tüm değişiklikleri içerir.

Sürüm notları, yeni modeli veya hattı vurgular ve sürümde yer alan diğer değişiklikleri de özetler. Yama sürümleri genellikle mevcut bir sürümdeki düzeltmeler için ayrılmıştır.

Diffusers, üç bileşenin tamamı için birkaç açık özellik isteğine sahiptir - eklemek istediğiniz belirli bileşeni henüz bilmiyorsanız, bunlara göz atabilirsiniz:

Üç bileşenden herhangi birini eklemeden önce, bu üç bileşenden herhangi birinin tasarımını daha iyi anlayabilmek için Felsefe kılavuzunu okumanız şiddetle tavsiye edilir. Tasarım felsefemizden önemli ölçüde sapan model, zamanlayıcı veya pipeline eklemelerini birleştiremeyeceğimizi lütfen dikkate alın; çünkü bu durum API tutarsızlıklarına yol açacaktır. Bir tasarım seçimiyle temel düzeyde katılmıyorsanız, belirli bir tasarım kalıbı/tasarım seçiminin kütüphanenin her yerinde değiştirilip değiştirilmeyeceği ve tasarım felsefemizin güncellenip güncellenmeyeceği tartışılabilmesi için bunun yerine bir Geri bildirim sorunu açın. Kütüphane genelindeki tutarlılık bizim için çok önemlidir.

Lütfen PR'ye orijinal kod tabanına/makaleye giden bağlantıları eklediğinizden emin olun ve mümkünse orijinal yazarı PR üzerinden doğrudan bilgilendirin; böylece ilerlemeyi takip edebilir ve sorularla ilgili yardımcı olabilirler.

PR'de emin değilseniz veya takılı kaldıysanız, ilk inceleme veya yardım istemek için bir mesaj bırakmaktan çekinmeyin.

mekanizmadan kopyalandı

Herhangi bir pipeline, model veya scheduler kodu eklerken kavranması gereken benzersiz ve önemli bir özellik, # Copied from mekanizmasıdır. Diffusers kod tabanının her yerinde bu mekanizmayı göreceksiniz ve bunun kullanılma nedeni, kod tabanının anlaşılmasını ve sürdürülmesini kolay tutmaktır. # Copied from mekanizmasıyla işaretlenen kod, kopyalandığı kodla birebir aynı olmak zorundadır. Bu sayede make fix-copies komutunu her çalıştırdığınızda değişiklikleri birçok dosya arasında güncellemek ve yaymak kolaylaşır.

Örneğin, aşağıdaki kod örneğinde StableDiffusionPipelineOutput orijinal kodu temsil ederken AltDiffusionPipelineOutput, # Copied from mekanizmasını kullanarak onu kopyalar. Tek fark, sınıf önekini Stable’den Alt’e değiştirmektir.

# 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.
    """

Daha fazla bilgi edinmek için ~Don’t~ Repeat Yourself* blog yazısının bu bölümünü okuyun.

İyi bir sorun nasıl yazılır

Sorununuz ne kadar iyi yazılırsa, hızlı çözülme olasılığı o kadar yüksek olur.

  1. Sorunuz için doğru şablonu kullandığınızdan emin olun. Bug Report, Feature Request, Feedback about API Design, New model/pipeline/scheduler addition veya boş bir sorun arasında seçim yapabilirsiniz. a new issue açarken doğru olanı seçtiğinizden emin olun. Kullanım soruları bir sorunda değil, GitHub Discussions bölümünde yer almalıdır.
  2. Net olun: Sorunuza uygun bir başlık verin. Sorun açıklamanızı olabildiğince basit bir şekilde ifade etmeye çalışın. Bir sorun bildirdiğinizde ne kadar isabetli olursanız, sorunun anlaşılması ve potansiyel olarak çözülmesi o kadar az zaman alır. Tek bir sorun için bir sorun açtığınızdan ve birden fazla sorun için tek bir sorun açmadığınızdan emin olun. Birden fazla sorun bulduysanız, basitçe birden fazla sorun açın. Sorununuz bir hata ise, hangi hata olduğunu olabildiğince net belirtmeye çalışın - sadece “diffusers’da hata” yazmamalısınız.
  3. Tekrarlanabilirlik: Tekrarlanabilir bir kod parçası yoksa çözüm de yoktur. Bir hata ile karşılaşırsanız, bakıcıların hatayı tekrarlayabilmesi gerekir. Sorunu yeniden oluşturmak için bir Python yorumcısına kopyala-yapıştır edilebilecek bir kod parçası içerdiğinden emin olun. Kod parçanızın çalıştığından, yani eksik importlar veya görsellere eksik bağlantılar olmadığından emin olun. Sorunuz, tam olarak aynı hata mesajını yeniden oluşturmak için herhangi bir değişiklik yapılmadan kopyala-yapıştır edilebilecek bir hata mesajı ve bir kod parçası içermelidir. Sorunuz, okuyucunun erişemeyeceği yerel model ağırlıkları veya yerel veriler kullanıyorsa, sorun çözülemez. Verilerinizi veya modelinizi paylaşamıyorsanız, sahte bir model veya sahte veriler oluşturmaya çalışın.
  4. Minimalist: Okuyucunun sorunu en kısa sürede anlayabilmesi için mümkün olduğunca kısa tutarak ona yardımcı olmaya çalışın. Soruyla ilgili olmayan tüm kodu / bilgiyi kaldırın. Bir hata bulduysanız, sorunu göstermek için en basit kod örneğini oluşturmaya çalışın; bir hata bulduğunuzda tüm iş akışınızı soruya yapıştırmayın. Örneğin, bir model eğitiyor ve eğitim sırasında bir noktada hata alıyorsanız, hatanın eğitim kodunun hangi kısmından kaynaklandığını anlamaya ve bunu birkaç satırla yeniden üretmeye çalışın. Tam veri setleri yerine sahte (dummy) veriler kullanmaya çalışın.
  5. Bağlam: Hata ile karşılaştığınızda veya özelliğe ihtiyaç duyduğunuzda üzerinde çalıştığınız şeyi bize anlatın; örneğin Diffusers üzerine kurulu bir uygulama, bir araştırma projesi veya kütüphanedeki hataları bulmak için çalıştırdığınız bir ajan. Bir-iki cümle yeterlidir ve projeye bir bağlantı eklemeniz memnuniyetle karşılanır. Aynı anda ele alabileceğimizden daha fazla sorun ve PR alıyoruz, bu nedenle bağlam, önceliklendirmeyi etkiye göre yapmamıza yardımcı olur.
  6. Bağlantılar ekleyin. Belirli bir adlandırma, yöntem veya modelden bahsediyorsanız, okuyucunun ne kastettiğinizi daha iyi anlayabilmesi için bir bağlantı sağladığınızdan emin olun. Belirli bir PR veya issue'dan bahsediyorsanız, bunu ilgili issue'unuza bağladığınızdan emin olun. Okuyucunun ne konuştuğunuzu bildiğini varsaymayın. Issue'unuza ne kadar çok bağlantı eklerseniz o kadar iyi olur.
  7. Biçimlendirme. Sorununuzun düzgün biçimlendirildiğinden emin olun; kodu Python kod sözdizimiyle, hata mesajlarını ise normal kod sözdizimiyle biçimlendirin. Daha fazla bilgi için resmî GitHub biçimlendirme belgelerini inceleyin.
  8. Sorunuzu çözülecek bir talep olarak değil, iyi yazılmış bir ansiklopedinin güzel bir maddesi olarak düşünün. Eklenen her sorun, herkese açık bilgiye bir katkıdır. İyi yazılmış bir sorun ekleyerek yalnızca geliştiricilerin sorununuzu çözmesini kolaylaştırmakla kalmaz, aynı zamanda topluluğun kütüphanenin belirli bir yönünü daha iyi anlamasına da yardımcı olursunuz.

İyi bir PR nasıl yazılır

  1. Her zaman bir sorundan (issue) başlayın. Çekme isteğinizin (pull request) ele aldığı sorunu bulun, kimse açmadıysa bir tane açın ve kod yazmadan önce bakımcılara (maintainer) yanıt verme fırsatı verin. Bizim için en iyi işe yarayan iş akışı, bir sorun açmak, ardından çözümün tartışılması ve bu tartışmaya dayalı olarak bir PR açmaktır. Bu, zamanımızı en etkili sorunlara odaklamamızı, kod var olmadan önce kapsamda anlaşmamızı ve tekrarlanan işten kaçınmamızı sağlar. PR açıklamasında sorun numarasını belirtin (ör. Fixes #1234) ki ikisi birbirine bağlansın.
  2. Bir bukalemun gibi olun. Mevcut tasarım kalıplarını ve sözdizimini anlayın ve kod eklemelerinizin mevcut kod tabanına kusursuz bir şekilde entegre olmasını sağlayın. Mevcut tasarım kalıplarından veya kullanıcı arayüzlerinden önemli ölçüde sapan pull request'ler birleştirilmeyecektir.
  3. Lazer gibi odaklanın. Bir pull request tek bir sorunu ve yalnızca o sorunu çözmelidir. “Bunu eklerken başka bir sorunu da düzeltelim” tuzağına düşmemeye dikkat edin. Birden fazla, birbirinden bağımsız sorunu aynı anda çözen pull request’leri incelemek çok daha zordur.
  4. Tekil durumlar değil, kalıpları düzeltin. Tek bir sorun birçok dosyaya yayılabilir: Aynı hata kod tabanında tekrarlıyorsa, tüm örnekleri arayın ve hepsini tek bir PR ile, net ve sistematik bir kapsamla (ör. “tüm zamanlayıcılarda değiştirilebilir varsayılanları düzelt”) düzeltin; her örnek için ayrı bir PR açmak yerine.
  5. Çekme isteğinizin başlığı, katkısının bir özeti olmalıdır. Devam eden bir işi belirtmek için başlığın başına [WIP] öneki ekleyin; bu, tekrarlanan işleri önler ve birleştirilmeye hazır olanlardan PR'ı ayırır.
  6. Metninizi İyi bir sorun nasıl yazılır başlığında açıklandığı gibi formüle etmeye ve biçimlendirmeye çalışın.
  7. PR açmadan önce kendi diff'inizi gözden geçirin. Bir gözden geçirenin yapacağı gibi okuyun ve bulduklarınızı düzeltin. self-review becerisini çalıştırmayı şiddetle öneririz: bu beceri, @claude CI gözden geçireninin kullandığı aynı değerlendirme ölçütünü uygular. Ajanınızı Yapay zeka ajanlarıyla kodlama başlıklı bölümde anlatıldığı gibi yapılandırın ve Yapay zeka destekli ve ajan tabanlı katkılar başlıklı bölümü takip edin. Açıklama kısmında, bilerek olduğu gibi bıraktığınız bulguları belirtin; böylece gözden geçiren, bunların bir ihmal değil bilinçli bir tercih olduğunu anlar.
  8. Mevcut testlerin geçtiğinden emin olun.
  9. Yüksek kapsamlı testler ekleyin. Kalite testi yoksa birleştirme yapılmaz.
  • Yeni @slow testleri ekliyorsanız, RUN_SLOW=1 python -m pytest tests/test_my_new_model.py komutuyla geçtiklerinden emin olun. CircleCI yavaş testleri çalıştırmaz, ancak GitHub Actions her gece çalıştırır!
  1. Tüm genel yöntemler, markdown ile iyi çalışan bilgilendirici docstring'ler içermelidir. Örnek için pipeline_latent_diffusion.py dosyasına bakın.
  2. Hızla büyüyen depoyu göz önünde bulundurarak, depoyu önemli ölçüde ağırlaştıracak dosyaların eklenmediğinden emin olmak önemlidir. Buna görseller, videolar ve diğer metin dışı dosyalar dahildir. Bu dosyaları yerleştirmek için hf-internal-testing veya huggingface/documentation-images gibi hf.co üzerinde barındırılan bir dataset kullanmayı tercih ediyoruz. Harici bir katkıda bulunuyorsanız, görselleri PR'ınıza ekleyebilir ve görsellerinizin bu veri setine taşınması için bir Hugging Face üyesinden rica edebilirsiniz.

PR açma

Kod yazmadan önce, aynı şey üzerinde zaten çalışılıp çalışılmadığından emin olmak için mevcut PR'ları veya sorunları aramanızı şiddetle tavsiye ederiz. Emin değilseniz, geri bildirim almak için bir sorun açmak her zaman iyi bir fikirdir.

🧨 Diffusers'a katkıda bulunabilmek için temel düzeyde git bilgisi gereklidir. git kullanması en kolay araç değildir ancak en kapsamlı kılavuza sahiptir. Bir kabukta git --help yazın ve keyfini çıkarın. Kitapları tercih ediyorsanız, Pro Git çok iyi bir başvuru kaynağıdır.

Katkıda bulunmaya başlamak için bu adımları izleyin (desteklenen Python sürümleri):

  1. Depoyu, sayfasındaki ‘Fork’ düğmesine tıklayarak forklayın. Bu işlem, kodun bir kopyasını GitHub kullanıcı hesabınız altında oluşturur.

  2. Fork'unuzu yerel diskinize klonlayın ve temel depoyu uzak (remote) olarak ekleyin:

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

  3. Geliştirme değişikliklerinizi tutmak için yeni bir dal oluşturun:

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

main dalında çalışmayın.

  1. Sanal bir ortamda aşağıdaki komutu çalıştırarak bir geliştirme ortamı oluşturun:

    $ pip install -e ".[dev]"

Depoyu zaten klonladıysanız, kütüphanedeki en son değişiklikleri almak için git pull yapmanız gerekebilir.

  1. Özellikleri dalınızda geliştirin.

Özellikler üzerinde çalışırken, test paketinin geçtiğinden emin olmalısınız. Değişikliklerinizin etkilediği testleri şu şekilde çalıştırmalısınız:

$ pytest tests/<TEST_TO_RUN>.py

Testleri çalıştırmadan önce, test için gerekli bağımlılıkları yüklediğinizden emin olun. Bunu şu komutla yapabilirsiniz:

$ pip install -e ".[test]"

Ayrıca tam test paketini aşağıdaki komutla da çalıştırabilirsiniz, ancak Diffusers önemli ölçüde büyüdüğü için makul bir sürede sonuç üretmek artık güçlü bir makine gerektirir. Komut şu şekildedir:

$ make test

🧨 Diffusers, kaynak kodunu tutarlı biçimde biçimlendirmek için black ve isort araçlarına dayanır. Değişikliklerinizi yaptıktan sonra, otomatikleştirilemeyen otomatik stil düzeltmelerini ve kod doğrulamalarını tek seferde şu komutla uygulayın:

$ make style

🧨 Diffusers ayrıca kodlama hatalarını kontrol etmek için ruff ve birkaç özel betik kullanır. Kalite kontrolü CI'de çalıştırılır; ancak aynı kontrolleri şu komutla da çalıştırabilirsiniz:

$ make quality

Değişikliklerinizden memnun kaldığınızda, değiştirilen dosyaları git add ile ekleyin ve değişikliklerinizi yerel olarak kaydetmek için git commit ile bir commit oluşturun:

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

Kodunuzun kopyasını orijinal depoyla düzenli olarak senkronize etmek iyi bir fikirdir. Bu sayede değişiklikleri hızla dikkate alabilirsiniz:

$ git pull upstream main

Değişiklikleri hesabınıza şu komutu kullanarak gönderin:

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

  1. Memnun kaldığınızda, GitHub'daki fork'unuzun web sayfasına gidin. Değişikliklerinizi proje yöneticilerine inceleme için göndermek için ‘Pull request’e tıklayın.

  2. Bakımcıların sizden değişiklikler istemesi normaldir. Bu durum çekirdek katkıda bulunanlara da olur! Herkesin Pull request içindeki değişiklikleri görebilmesi için yerel dalınızda çalışın ve değişiklikleri forkunuza gönderin. Değişiklikler pull request içinde otomatik olarak görünecektir.

Testler

Kütüphanenin davranışını ve çeşitli örnekleri test etmek için kapsamlı bir test paketi dahildir. Kütüphane testleri tests klasöründe bulunabilir.

pytest ve pytest-xdist daha hızlı olduğu için tercih ediyoruz. Deponun kök dizininden, kütüphane için pytest ile testleri çalıştırmak için:

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

Aslında make test tam olarak bu şekilde uygulanır!

Çalıştığınız özelliği test etmek için daha küçük bir test seti belirleyebilirsiniz.

Varsayılan olarak yavaş testler atlanır. Çalıştırmak için RUN_SLOW ortam değişkenini yes olarak ayarlayın. Bu işlem, gigabaytlarca model indirecektir — yeterli disk alanına ve iyi bir internet bağlantısına sahip olduğunuzdan ya da bolca sabrınız olduğundan emin olun!

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

unittest tam olarak desteklenmektedir, bununla testleri çalıştırmanın yolu şudur:

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

Fork edilmiş main'in upstream (HuggingFace) main ile senkronize edilmesi

Yukarıdaki PR'lere referans notları ekleyen ve bu PR'lere dahil olan geliştiricilere gereksiz bildirimler gönderen üst akış deposuna istek göndermekten kaçınmak için, çatal bir depoda ana dalı senkronize ederken lütfen şu adımları izleyin:

  1. Mümkün olduğunda, fork edilmiş depoda bir dal ve PR kullanarak upstream ile senkronize olmaktan kaçının. Bunun yerine, doğrudan fork edilmiş main dalına birleştirin.
  2. Bir PR kesinlikle gerekiyorsa, dalınızı kontrol ettikten sonra aşağıdaki adımları kullanın:
$ 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

Stil kılavuzu

Belge dizeleri için 🧨 Diffusers, Google stilini uygular.

Yapay zeka ajanlarıyla kodlama

Depo, AI-ajan yapılandırmasını .ai/ içinde tutar; bu yapılandırma ayrıca bir ajan eklentisi olarak da yayınlanır, böylece talep üzerine görev becerileri tek adımda kurulur.

  • Katkıda bulunanlar için salt okunur — .ai/ ana bakım sorumluları tarafından yönetilir. Lütfen PR'ınızda .ai/ altındaki dosyaları (veya kök düzeyindeki AGENTS.md / CLAUDE.md sembolik bağlantılarını, ya da kurulu .agents/skills / .claude/skills dizinlerini) düzenlemeyin. Eksik veya hatalı bir şey fark ederseniz bir sorun (issue) açın veya PR'da belirtin; bir bakım sorumlusu güncelleyecektir.
  • Guidelines — .ai/AGENTS.md kök dizindeki AGENTS.md / CLAUDE.md sembolik bağlantıları aracılığıyla her ajan oturumuna yüklenir; .ai/references/ altındaki referans kılavuzları, bir bağlantı izlendiğinde ihtiyaç halinde okunur:
  • Skills (altında .ai/skills/, belirli görevler için isteğe bağlı olarak yüklenir:
    • model-integration — diffusers'a yeni bir model veya pipeline eklemek (dosya yapısı, entegrasyon kontrol listesi, test düzeni, ağırlık dönüşümü)
    • self-review — bir PR açmadan önce değişikliklerinizi proje kurallarına göre gözden geçirin
    • diffusers-cli — terminalden pipeline çalıştırma ve şemaları inceleme
    • custom-blocks — Hub için bir ModularPipelineBlocks alt sınıfını paketleme

Hangi yolu seçerseniz seçin, başlamadan önce aracınızın kendi kurulumunu doğrulamasını isteyin — python utils/check_ai.py kılavuzların ve becerilerin tutarlı olduğunu kontrol eder, diffusers-cli skills list ise aracın gerçekten hangi becerilere sahip olduğunu gösterir.

Yapay zeka destekli ve ajan tabanlı katkılar

Diffusers'a katkıda bulunmak için yapay zeka ajanları memnuniyetle karşılanır. Ajanınızı Diffusers ajan kılavuzu ile yapılandırmanızı ve model-integration ile self-review gibi ilgili görevlere özel becerileri kullanmanızı öneririz. Yukarıda belirtildiği gibi eklentiyi (veya bireysel becerileri) yükleyin, ardından kılavuza göre katkınızı kapsamlandırın, uygulayın, test edin ve gözden geçirin. PR'ınızdaki değişiklikleri anlama, test etme ve sürdürme sorumluluğu size aittir.

Yapay zeka destekli katkılar memnuniyetle karşılanır, ancak inceleme yükünü yönetilebilir tutmak için koordine edilmiş, kapsamı belirlenmiş ve doğrulanmış olmalıdır. Bu yönergeleri takip etmeyen PR'lar, ayrıntılı inceleme yapılmadan kapatılabilir.

  • PR açmadan önce koordinasyon sağlayın. Bir issue bulun veya açın, benzer PR'leri (açık olanları ve yakın zamanda kapatılanları) inceleyin ve PR açmadan önce bir bakıcının (maintainer) o issue üzerinde açık bir onay vermesini bekleyin. Bu, kapsamı tartışmamıza, tekrarlanan işleri önlememize ve yaklaşımı onaylamamıza olanak tanır.
  • Desenleri düzeltin, tek seferlik durumları değil. Tekrarlayan bir sorun fark ederseniz, kod tabanında benzer örnekleri arayın ve tekil örnekler için birçok sorun veya PR açmak yerine, net ve sistematik bir kapsamla (ör. “tüm zamanlayıcılarda değiştirilebilir varsayılanları düzelt”) tek bir sorun açın.
  • Açmadan önce kendi kendine inceleme. self-review becerisini çalıştırın — bu beceri, @claude CI inceleyicisinin kullandığı aynı ölçüt olan .ai/references/review-rules.md dosyasına göre diff'inizi inceler — ve raporladıklarını ele alın; bu bir yardımcıdır, yetkili değildir ve yanılabilir. Size mantıklı gelen engelleyici sorunlara odaklanın ve mümkün olduğunca ölü/kullanılmayan kodu temizleyin. Bir öneriyle katılmıyorsanız, PR açıldıktan sonra inceleyicinin tartışması için bırakmanız sorun değildir — paylaştığınız notlar (aşağıda) inceleyiciye bunun bilinçli bir karar olduğunu söyler.
  • Kendi inceleme notlarınızı paylaşın. Gönderdiğiniz diff'i yansıtan tur olan nihai kendi inceleme raporunu, PR'da açıklamada veya bir yorum olarak, bilerek düzeltmediğiniz bulguları ve nedenlerini de içerecek şekilde paylaşın. Bu, inceleyicinin nelerin zaten kontrol edildiğini ve hangi kararların bilinçli verildiğini görmesini sağlar ve genellikle birkaç tur ileri geri tartışmasını önler.
  • PR iletişiminizi kısa tutun. Bir gözden geçirmenin PR'ınızda okuduğu her şey — açıklama, commit mesajları, yorumlar ve yanıtlar, kod yorumları — bir insan tarafından kolayca anlaşılabilir olmalıdır. Metni ajanınız hazırladıysa, sadece göz atmayın. Metni okuyun ve ajanı, kendinizin de yazacağı mantıklı ve kısa bir ifadeye dönüştürmesi için revize etmesini isteyin. Yayınladığınız her şeyin yazarı sizsiniz.
  • Include in the PR description:
    • Bir bakıcının (maintainer) çalışmayı onayladığı soruna veya tartışmaya giden koordinasyon bağlantısı.
    • Çalıştırdığınız test komutları ve sonuçları (yalnızca “testler geçiyor” değil, ilgili çıktıyı yapıştırın).
    • Yukarıda açıklandığı gibi, kendi inceleme notlarınız (veya bunları içeren PR yorumuna bir bağlantı).

Bir model yazarıysanız veya bir modeli resmi olarak bakımını yapan bir ekibin parçasıysanız, yeni bir model entegrasyonu için ajan kullanmanızı öneririz. Deponun önerilen kurulumunu izleyin ve model-integration becerisini kullanın. Bir PR açmadan önce kapsamı bakım sorumlularıyla koordine edin — bkz. Pipeline, model ve zamanlayıcı ekleme.

Update on GitHub

←Diffusers ile oluşturulan projeler Diffusers Etik İlkeleri→