Buckets:
| # Diffusers'a nasıl katkıda bulunulur 🧨 | |
| > [!TIP] | |
| > Bir yapay zeka ajanı kullanarak katkıda bulunuyorsanız, beklentilerimizi ve yönergelerimizi içeren [Yapay zeka destekli ve ajan tabanlı katkılar](#ai-assisted-and-agentic-contributions) 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 işe gönül veriyorsanız çekinmeyin ve 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 ☕. | |
| 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ı](https://github.com/huggingface/diffusers/blob/main/CODE_OF_CONDUCT.md) okuyun ve etkileşimleriniz sırasında bunlara saygı göstermeye özen gösterin. Ayrıca, projemizi yönlendiren [etik ilkelerle](https://huggingface.co/docs/diffusers/conceptual/ethical_guidelines) 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 zorluk sırasına göre farklı katkı yollarının bir özetini sunuyoruz. Bunların tümü topluluk için değerlidir. | |
| * 1. [Diffusers tartışma forumunda](https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers) veya [Discord](https://discord.gg/G7tWnz98XR)'da soru sormak ve cevaplamak. | |
| * 2. [GitHub Sorunlar sekmesinde](https://github.com/huggingface/diffusers/issues/new/choose) yeni sorunlar açmak veya [GitHub Tartışmalar sekmesinde](https://github.com/huggingface/diffusers/discussions/new/choose) yeni tartışmalar başlatmak. | |
| * 3. [GitHub Sorunlar sekmesindeki](https://github.com/huggingface/diffusers/issues) sorunlara veya [GitHub Tartışmalar sekmesindeki](https://github.com/huggingface/diffusers/discussions) tartışmalara yanıt vermek. | |
| * 4. "Good first issue" etiketiyle işaretlenmiş basit bir sorunu çözün, bkz. [burası](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22). | |
| * 5. [belgelere](https://github.com/huggingface/diffusers/tree/main/docs/source) katkıda bulunun. | |
| * 6. Bir [Topluluk Hattı](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3Acommunity-examples) katkıda bulunun. | |
| * 7. [örnekler](https://github.com/huggingface/diffusers/tree/main/examples) bölümüne katkıda bulunun. | |
| * 8. "Good second issue" etiketiyle işaretlenmiş daha zor bir sorunu çözün, bkz. [burası](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+second+issue%22). | |
| * 9. Yeni bir pipeline, model veya scheduler ekleyin, ["New Pipeline/Model"](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22New+pipeline%2Fmodel%22) ve ["New scheduler"](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22New+scheduler%22) sorunlarına bakın. Bu katkı için lütfen [Design Philosophy](https://huggingface.co/docs/diffusers/main/en/conceptual/philosophy) bölümüne göz atın. | |
| 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 - 9 aralığındaki tüm katkılar için bir PR açmanız gerekecektir. Bunun nasıl yapılacağı [Opening a pull request](#how-to-open-a-pr) başlığında ayrıntılı olarak açıklanmıştır. | |
| ### 1. Diffusers tartışma forumunda veya Diffusers Discord üzerinde soru sormak ve yanıtlamak | |
| Diffusers kütüphanesiyle ilgili herhangi bir soru veya yorum, [tartışma forumunda](https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers/) veya [Discord](https://discord.gg/G7tWnz98XR) üzerinde 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 | |
| - ... | |
| Forumda 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 büyük olasılıkla yardımcı olur. Lütfen aklınıza takılan her soruyu sormaktan çekinmeyin. Aynı ruhla, bu tür soruları yanıtlayarak topluluğa büyük katkıda bulunursunuz; çü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 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](#how-to-write-a-good-issue) bölümüne göz atmanızı öneririz. | |
| **Kanallar hakkında NOT**: [*Forum*](https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers/63), Google gibi arama motorları tarafından çok daha iyi indekslenir. Gönderiler kronolojik sırayla değil, popülerliğe göre sıralanır. Bu nedenle, daha önce paylaştığımız soruları ve yanıtları aramak daha kolaydır. Ayrıca forumda paylaşılan sorulara ve yanıtlara kolayca bağlantı verilebilir. Buna karşılık, *Discord* hızlı ileri-geri iletişimi teşvik eden sohbet benzeri bir formata sahiptir. Sorunuzun Discord'da yanıtlanması muhtemelen daha kısa sürede gerçekleşse de, zamanla sorunuz görünmez hale gelir. Ayrıca Discord'da bir süre önce paylaşılan bilgileri bulmak çok daha zordur. Bu nedenle, topluluk için kalıcı bir bilgi birikimi oluşturma çabasıyla yüksek kaliteli soru ve yanıtlar için forumu kullanmanızı şiddetle öneririz. Discord'daki tartışmalar çok ilginç yanıtlara ve sonuçlara yol açıyorsa, bu bilgilerin gelecekteki okuyucular için daha erişilebilir hale gelmesi adına sonuçları forumda paylaşmanızı öneririz. | |
| ### 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 on GitHub, but rather on either the [forum](https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers/63) or [Discord](https://discord.gg/G7tWnz98XR). | |
| **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, lütfen | |
| yine de yeni bir sorun açın ve ilgili soruna bağlantı verin. | |
| - Sorunuzun İngilizce olarak yazıldığından emin olun. İngilizceye hâkim değilseniz, yerel dilinizden İngilizceye çeviri için [DeepL](https://www.deepl.com/translator) gibi harika, ücretsiz çevrimiçi çeviri hizmetlerinden birini kullanın. | |
| - 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 şunları 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](https://huggingface.co) ü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](#how-to-write-a-good-issue) bölümüne göz atın. | |
| Bir hata raporu açmak için [buraya](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=bug&projects=&template=bug-report.yml) 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 açıklayın | |
| nedeni. Sorunu gösteren bir kod parçası paylaşmak en iyisidir. | |
| * Bir proje için ihtiyaç duyacağınız bir şeyle ilgili mi? Duymaktan memnuniyet duyarız | |
| hakkında! | |
| * Üzerinde çalıştığınız ve topluluğa fayda sağlayabileceğini düşündüğünüz bir şey mi? | |
| Harika! Bize sizin için hangi sorunu çözdüğünü söyleyin. | |
| 2. Özelliği açıklayan *tam bir paragraf* yazın; | |
| 3. Gelecekteki kullanımını gösteren bir **kod parçası** sağlayın; | |
| 4. Eğer bu bir makaleyle ilgiliyse, lütfen bir bağlantı ekleyin; | |
| 5. 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](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feature_request.md&title=) 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](https://huggingface.co/docs/diffusers/conceptual/philosophy) 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; çünkü bu, gelecekteki tasarım kararları için harika bir geri bildirimdir. | |
| Geri bildirimle ilgili bir sorun [burada](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feedback.md&title=) 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ı sağlayın. | |
| Teknik bir soruyla ilgili bir sorun [burada](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=bug&template=bug-report.yml) 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ı. | |
| Modeli kendiniz geliştirmek isterseniz, size en iyi şekilde rehberlik edebilmemiz için bize bildirin. Ayrıca, bileşenin (model, zamanlayıcı, boru hattı vb.) orijinal yazarını bulabiliyorsanız, GitHub kullanıcı adıyla etiketlemeyi unutmayın. | |
| Bir model/pipeline/scheduler için talep oluşturmak için [buraya](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=New+model%2Fpipeline%2Fscheduler&template=new-model-addition.yml) 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 vermenin 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 net olmaya teşvik etmeniz, tekrarlanan soruna bağlantı vermeniz veya onları [forum](https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers/63) veya [Discord](https://discord.gg/G7tWnz98XR) kanalına 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. | |
| Aşağıdaki tüm katkılar için bir PR açmanız gerekecektir. Bunun nasıl yapılacağı [Opening a pull request](#how-to-open-a-pr) bölümünde ayrıntılı olarak açıklanmıştır. | |
| ### 4. "Good first issue" düzeltme | |
| *İlk iyi sorunlar*, [İlk iyi sorun](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) 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 önermiyor. Bu durumda, olası bir düzeltmenin nasıl görünebileceğini sorabilirsiniz ve Diffusers ekibinden biri kısa süre içinde yanıt vermelidir. Nasıl düzeltileceğine dair iyi bir fikriniz varsa, doğrudan bir PR açmaktan çekinmeyin. | |
| - 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 bir anda devam etmek için zaman bulamazsa 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 bir şans vermenizden ç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](https://huggingface.co/docs/diffusers/index) görüntülenen her şey resmi dokümantasyonun bir parçasıdır ve ilgili [dokümantasyon kaynağında](https://github.com/huggingface/diffusers/tree/main/docs/source) düzeltilebilir veya ayarlanabilir. | |
| Belgelerdeki değişikliklerin yerel olarak nasıl doğrulanacağına dair [bu sayfaya](https://github.com/huggingface/diffusers/tree/main/docs) göz atın. | |
| ### 6. Topluluk hattına katkıda bulunun | |
| > [!TIP] | |
| > GitHub ve Hugging Face Hub topluluk hattı arasındaki farkı öğrenmek için [Community pipelines](../using-diffusers/custom_pipeline_overview#community-pipelines-and-components) rehberini okuyun. Topluluk hatlarının neden var olduğunu merak ediyorsanız, GitHub Issue [#841](https://github.com/huggingface/diffusers/issues/841) konusuna göz atın (temel olarak, difüzyon modellerinin çıkarım için kullanılabileceği tüm olası yolları sürdürmek mümkün değil ancak topluluğun bunları oluşturmasını da engellemek istemiyoruz). | |
| Bir topluluk hattı (pipeline) katkıda bulunmak, yaratıcılığınızı paylaşmanın ve toplulukla birlikte çalışmanın harika bir yoludur. Bu sayede [DiffusionPipeline](/docs/diffusers/main/tr/api/pipelines/overview#diffusers.DiffusionPipeline) üzerine inşa edebilir ve `custom_pipeline` parametresini ayarlayarak herkesin hattı yükleyip kullanmasını sağlayabilirsiniz. Bu bölümde, UNet'in yalnızca tek bir ileri geçiş (forward pass) yapması ve zamanlayıcıyı (scheduler) bir kez çağırmasıyla çalışan basit bir hat (bir "tek adımlık" hat) oluşturma sürecini adım adım ele alacağız. | |
| 1. Topluluk hattınız için one_step_unet.py adlı bir dosya oluşturun. Bu dosya, kullanıcının kurduğu herhangi bir paketi içerebilir. Hub'dan model ağırlıklarını ve zamanlayıcı yapılandırmasını yüklemek için yalnızca [DiffusionPipeline](/docs/diffusers/main/tr/api/pipelines/overview#diffusers.DiffusionPipeline)'dan türeyen tek bir hat sınıfı olduğundan emin olun. `__init__` fonksiyonuna bir UNet ve zamanlayıcı ekleyin. | |
| Hattınızın ve bileşenlerinin [save_pretrained()](/docs/diffusers/main/tr/api/pipelines/overview#diffusers.DiffusionPipeline.save_pretrained) ile kaydedilebilmesini sağlamak için `register_modules` fonksiyonunu da eklemelisiniz. | |
| ```py | |
| from diffusers import DiffusionPipeline | |
| import torch | |
| class UnetSchedulerOneForwardPipeline(DiffusionPipeline): | |
| def __init__(self, unet, scheduler): | |
| super().__init__() | |
| self.register_modules(unet=unet, scheduler=scheduler) | |
| ``` | |
| 1. İleri geçişte (bunu `__call__` olarak tanımlamanızı öneririz) istediğiniz herhangi bir özelliği ekleyebilirsiniz. "Tek adımlı" boru hattı için rastgele bir görüntü oluşturun ve `timestep=1` ayarlayarak UNet ve zamanlayıcıyı bir kez çağırın. | |
| ```py | |
| from diffusers import DiffusionPipeline | |
| import torch | |
| class UnetSchedulerOneForwardPipeline(DiffusionPipeline): | |
| def __init__(self, unet, scheduler): | |
| super().__init__() | |
| self.register_modules(unet=unet, scheduler=scheduler) | |
| def __call__(self): | |
| image = torch.randn( | |
| (1, self.unet.config.in_channels, self.unet.config.sample_size, self.unet.config.sample_size), | |
| ) | |
| timestep = 1 | |
| model_output = self.unet(image, timestep).sample | |
| scheduler_output = self.scheduler.step(model_output, timestep, image).prev_sample | |
| return scheduler_output | |
| ``` | |
| Şimdi, bir UNet ve zamanlayıcı (scheduler) iletmek suretiyle hattı (pipeline) çalıştırabilir veya hat yapısı aynıysa önceden eğitilmiş ağırlıkları yükleyebilirsiniz. | |
| ```py | |
| from diffusers import DDPMScheduler, UNet2DModel | |
| scheduler = DDPMScheduler() | |
| unet = UNet2DModel() | |
| pipeline = UnetSchedulerOneForwardPipeline(unet=unet, scheduler=scheduler) | |
| output = pipeline() | |
| # load pretrained weights | |
| pipeline = UnetSchedulerOneForwardPipeline.from_pretrained("google/ddpm-cifar10-32", use_safetensors=True) | |
| output = pipeline() | |
| ``` | |
| Pipeline'ınızı bir GitHub topluluk pipeline'ı veya Hub topluluk pipeline'ı olarak paylaşabilirsiniz. | |
| GitHub hattınızı, Diffusers [deposu](https://github.com/huggingface/diffusers) üzerinde bir çekme isteği (pull request) açarak paylaşın ve [examples/community](https://github.com/huggingface/diffusers/tree/main/examples/community) alt klasörüne one_step_unet.py dosyasını ekleyin. | |
| Hub'daki model deposunu oluşturarak ve one_step_unet.py dosyasını yükleyerek Hub'daki pipeline'ınızı paylaşın. | |
| ### 7. Eğitim örneklerine katkıda bulunun | |
| Diffusers örnekleri, [examples](https://github.com/huggingface/diffusers/tree/main/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](https://github.com/huggingface/diffusers/tree/main/examples/research_projects) konumunda yer alırken resmi eğitim örnekleri, `research_projects` ve `community` klasörleri hariç olmak üzere [examples](https://github.com/huggingface/diffusers/tree/main/examples) altındaki tüm klasörleri içerir. Resmi eğitim örnekleri Diffusers'ın çekirdek bakımcıları tarafından, araştırma eğitim örnekleri ise topluluk tarafından sürdürülmektedir. Bunun nedeni, resmi ve topluluk pipeline'ları için [6. Bir topluluk pipeline'ı katkıda bulunun](#6-contribute-a-community-pipeline) bölümünde öne sürülen nedenlerle aynıdır: Çekirdek bakımcıların difüzyon modelleri için olası tüm eğitim yöntemlerini sürdürmesi mümkün değildir. Diffusers çekirdek 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: | |
| ```bash | |
| git clone https://github.com/huggingface/diffusers | |
| ``` | |
| ve eğitim için gerekli tüm ek bağımlılıkları yüklemek için: | |
| ```bash | |
| cd diffusers | |
| pip install -r examples/<your-example-folder>/requirements.txt | |
| ``` | |
| Dolayısıyla bir örnek eklerken, `requirements.txt` dosyası, eğitim örneğiniz için gerekli tüm pip bağımlılıklarını tanımlamalıdır; böylece bunların tümü yüklendikten sonra kullanıcı, örneğin eğitim betiğini çalıştırabilir. Örneğin, [DreamBooth `requirements.txt` dosyasına](https://github.com/huggingface/diffusers/blob/main/examples/dreambooth/requirements.txt) bakın. | |
| 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](https://github.com/huggingface/diffusers/blob/main/examples/dreambooth/train_dreambooth.py) 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](https://github.com/huggingface/accelerate) 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](https://github.com/huggingface/diffusers/tree/main/examples/dreambooth#running-locally-with-pytorch). | |
| - Kullanıcının ne bekleyebileceğini gösteren bazı eğitim sonuçlarına (günlükler, modeller vb.) [buradaki](https://api.wandb.ai/report/patrickvonplaten/xm6cd5q5) 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](https://github.com/huggingface/diffusers/tree/main/examples/research_projects/intel_opts#diffusers-examples-with-intel-optimizations) gösterildiği gibi yer almalıdır. | |
| Resmi eğitim örneklerine katkıda bulunuyorsanız, [examples/dreambooth/test_dreambooth.py](https://github.com/huggingface/diffusers/blob/main/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" düzeltme | |
| *İyi ikinci sorunlar*, [İyi ikinci sorun](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+second+issue%22) etiketiyle işaretlenir. İyi ikinci sorunlar genellikle [İyi ilk sorunlardan](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) daha karmaşıktır. Sorun açıklaması, sorunun nasıl düzeltileceğine dair genellikle daha az yönlendirme sunar ve ilgili katkıda bulunan kişiden kütüphanenin makul bir düzeyde anlaşılmasını gerektirir. Bir iyi ikinci sorunla ilgileniyorsanız, onu düzeltmek için bir PR açmaktan ve PR'ı soruna bağlamaktan çekinmeyin. Bu sorun için zaten bir PR açılmış ancak birleştirilmemişse, neden birleştirilmediğini anlamak için inceleyin ve geliştirilmiş bir PR açmayı deneyin. İyi ikinci sorunlar, iyi ilk sorunlara kıyasla genellikle birleştirilmesi daha zor olduğundan, çekirdek bakımcılardan yardım istemekten çekinmeyin. PR'ınız neredeyse tamamsa, çekirdek bakımcılar birleştirilmesi için PR'ınıza dahil olup commit atabilir. | |
| ### 9. Boru hatları, modeller ve zamanlayıcılar ekleme | |
| > [!TIP] | |
| > 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 olan bir isteğe yorum bırakın. | |
| > | |
| > Bir topluluk katkıcısıysanız, lütfen özellik isteğinin altında ilginizi bildirin ve aynı anda bir Hub deposuyla başlayın. Başlamak için [Modular Diffusers](../modular_diffusers/overview) kılavuzuna bakın ve Hub üzerinde uzaktan kod olarak yayınlamak için [custom blocks](../modular_diffusers/custom_blocks) veya [custom models](../using-diffusers/automodel) konularına göz atın. | |
| 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ğlayarak topluluğun güçlü üretken yapay zeka uygulamaları geliştirmesine 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 `diffusers@huggingface.co` 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: | |
| - [Model veya pipeline](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22New+pipeline%2Fmodel%22) | |
| - [Zamanlayıcı](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22New+scheduler%22) | |
| Üç bileşenden herhangi birini eklemeden önce, bu üç bileşenden herhangi birinin tasarımını daha iyi anlayabilmek için [Felsefe kılavuzu](philosophy)nu 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, lütfen bunun yerine bir [Geri bildirim sorunu](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feedback.md&title=) açın; böylece 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ışılabilir. 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](/docs/diffusers/main/tr/api/pipelines/stable_diffusion/img2img#diffusers.pipelines.stable_diffusion.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. | |
| ```py | |
| # 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*](https://huggingface.co/blog/transformers-design-philosophy#4-machine-learning-models-are-static) 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*, *Forum* veya boş bir sorun arasında seçim yapabilirsiniz. [yeni bir sorun](https://github.com/huggingface/diffusers/issues/new/choose) açarken doğru olanı seçtiğinizden emin olun. | |
| 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ğ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. | |
| 6. 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](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) inceleyin. | |
| 7. 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. 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. | |
| 2. 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. | |
| 3. İşe yarayacaksa, eklemenizin nasıl kullanılabileceğini gösteren bir kod parçası eklemeye çalışın. | |
| 4. Çekme isteğinizin başlığı, katkısının bir özeti olmalıdır. | |
| 5. Çekme isteğiniz bir sorunu ele alıyorsa, lütfen | |
| bağlantıların doğru kurulduğundan emin olmak için pull request açıklamasına ekleyin (ve sorunu inceleyen kişilerin üzerinde çalıştığınızı bilmelerini sağlayın); | |
| 6. Devam eden bir çalışmayı belirtmek için başlığın başına `[WIP]` öneki ekleyin. Bunlar | |
| mükerrer işleri önlemek ve birleştirilmeye hazır PR'lerden ayırt etmek için kullanışlıdır; | |
| 7. Metninizi [İyi bir sorun nasıl yazılır](#how-to-write-a-good-issue) başlığında açıklandığı gibi formüle etmeye ve biçimlendirmeye çalışın. | |
| 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, bunların | |
| `RUN_SLOW=1 python -m pytest tests/test_my_new_model.py`. CircleCI yavaş testleri çalıştırmaz, ancak GitHub Actions her gece çalıştırır! | |
| 10. Tüm genel yöntemler, markdown ile iyi çalışan bilgilendirici docstring'ler içermelidir. Örnek için [`pipeline_latent_diffusion.py`](https://github.com/huggingface/diffusers/blob/main/src/diffusers/pipelines/latent_diffusion/pipeline_latent_diffusion.py) dosyasına bakın. | |
| 11. 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. Bunun yerine, `dataset` gibi hf.co üzerinde barındırılan | |
| [`hf-internal-testing`](https://huggingface.co/hf-internal-testing) veya [huggingface/documentation-images](https://huggingface.co/datasets/huggingface/documentation-images) konumuna bu dosyaları yerleştirin. Harici bir katkı söz konusuysa, görselleri PR'ınıza ekleyebilir ve bir Hugging Face üyesinden görsellerinizi bu veri setine taşımasını isteyebilirsiniz. | |
| ## PR açma | |
| Kod yazmadan önce, aynı konuda başka birinin zaten çalışmadığı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ılavuzlara sahiptir. Bir kabukta `git --help` yazın ve keyfini çıkarın. Kitapları tercih ediyorsanız, [Pro Git](https://git-scm.com/book/en/v2) çok iyi bir başvuru kaynağıdır. | |
| Katkıda bulunmaya başlamak için bu adımları izleyin ([desteklenen Python sürümleri](https://github.com/huggingface/diffusers/blob/83bc6c94eaeb6f7704a2a428931cf2d9ad973ae9/setup.py#L270)): | |
| 1. [deponun](https://github.com/huggingface/diffusers) bir kopyasını oluşturmak için | |
| depozitonun sayfasındaki 'Fork' düğmesine tıklayarak. Bu, kodun bir kopyasını GitHub kullanıcı hesabınızın altında oluşturur. | |
| 2. Fork'unuzu yerel diskinize klonlayın ve temel depoyu uzak (remote) olarak ekleyin: | |
| ```bash | |
| $ git clone git@github.com:<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: | |
| ```bash | |
| $ git checkout -b a-descriptive-name-for-my-changes | |
| ``` | |
| `main` dalında **çalışmayın**. | |
| 4. Sanal bir ortamda aşağıdaki komutu çalıştırarak bir geliştirme ortamı oluşturun: | |
| ```bash | |
| $ 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. | |
| 5. Ö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: | |
| ```bash | |
| $ 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: | |
| ```bash | |
| $ pip install -e ".[test]" | |
| ``` | |
| Ayrıca, aşağıdaki komutla tam test paketini de çalıştırabilirsiniz; ancak Diffusers oldukça büyüdüğü için artık makul bir sürede sonuç almak için güçlü bir makineye ihtiyaç vardır. Komut şu şekildedir: | |
| ```bash | |
| $ 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: | |
| ```bash | |
| $ make style | |
| ``` | |
| 🧨 Diffusers ayrıca kodlama hatalarını kontrol etmek için `ruff` ve birkaç özel betik kullanır. Kalite kontrolü CI'da çalıştırılır; ancak aynı kontrolleri şu komutla da çalıştırabilirsiniz: | |
| ```bash | |
| $ 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: | |
| ```bash | |
| $ git add modified_file.py | |
| $ git commit -m "A descriptive message about your changes." | |
| ``` | |
| Kodunuzun kopyasını düzenli olarak orijinal depoyla senkronize etmek iyi bir fikirdir. Bu sayede değişiklikleri hızla dikkate alabilirsiniz: | |
| ```bash | |
| $ git pull upstream main | |
| ``` | |
| Değişiklikleri hesabınıza şu komutu kullanarak gönderin: | |
| ```bash | |
| $ git push -u origin a-descriptive-name-for-my-changes | |
| ``` | |
| 6. Memnun kaldığınızda, | |
| GitHub'daki fork'unuzun web sayfası. Değişikliklerinizi proje yöneticilerine inceleme için göndermek için 'Pull request' seçeneğine tıklayın. | |
| 7. Bakımcıların sizden değişiklikler istemesi normaldir. Bu durum çekirdek katkıda bulunanlara da olur. | |
| de! Böylece herkes Pull request'teki değişiklikleri görebilir; yerel dalınızda çalışın ve değişiklikleri fork'unuza gönderin. Değişiklikler pull request'te 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](https://github.com/huggingface/diffusers/tree/main/tests) 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: | |
| ```bash | |
| $ 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! | |
| ```bash | |
| $ 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: | |
| ```bash | |
| $ 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: | |
| ```bash | |
| $ 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 stili](https://google.github.io/styleguide/pyguide.html)ni uygular. | |
| ## Yapay zeka ajanlarıyla kodlama | |
| Depo, AI-ajan yapılandırmasını [`.ai/`](https://github.com/huggingface/diffusers/tree/main/.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. | |
| - **Kılavuzlar** — `.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: | |
| - [`.ai/AGENTS.md`](https://github.com/huggingface/diffusers/blob/main/.ai/AGENTS.md) — üst düzey kodlama yönergeleri | |
| - [`.ai/references/models.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/models.md) — dikkat deseni, model uygulama kuralları, yaygın sözleşmeler | |
| - [`.ai/references/pipelines.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/pipelines.md) — pipeline kuralları | |
| - [`.ai/references/modular.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/modular.md) — modüler pipeline kuralları ve dönüştürme kontrol listesi | |
| - [`.ai/references/testing.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/testing.md) — zorunlu test katmanları, tester karışımları, sahte bileşen kuralları | |
| - [`.ai/references/review-rules.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/review-rules.md) — inceleyicilerin aradığı şeyler | |
| - **Beceriler** ([`.ai/skills/`](https://github.com/huggingface/diffusers/tree/main/.ai/skills) altında, belirli görevler için talep üzerine 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](https://github.com/huggingface/diffusers/blob/main/.ai/AGENTS.md) 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`](https://github.com/huggingface/diffusers/blob/main/.ai/skills/self-review/SKILL.md) becerisini çalıştırın — bu beceri, `@claude` CI inceleyicisinin kullandığı aynı ölçüt olan [`.ai/references/review-rules.md`](https://github.com/huggingface/diffusers/blob/main/.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'a, açıklamaya veya bir yorum olarak, bilerek düzeltmediğiniz bulguları ve nedenlerini de içerecek şekilde ekleyin. 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. | |
| - **PR açıklamasına şunları ekleyin:** | |
| - 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](https://github.com/huggingface/diffusers/blob/main/.ai/AGENTS.md) izleyin ve [`model-integration`](https://github.com/huggingface/diffusers/blob/main/.ai/skills/model-integration/SKILL.md) becerisini kullanın. Bir PR açmadan önce kapsamı bakım sorumlularıyla koordine edin — bkz. [Pipeline, model ve zamanlayıcı ekleme](#9-adding-pipelines-models-schedulers). | |
Xet Storage Details
- Size:
- 55.2 kB
- Xet hash:
- 568052d1099d5d3452c598ff75dab1f1d596f5203db642c53f9e19fddbc904bc
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.