Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
255 lines (161 loc) · 12.6 KB

CONTRIBUTING.md

File metadata and controls

255 lines (161 loc) · 12.6 KB

Angular'a Katkıda Bulunma

Angular'a katkıda bulunmanızı ve bugünkünden daha iyi hale getirmenize yardımcı olmanızı çok isteriz! Bir katkıda bulunan olarak, uymanızı istediğimiz kurallar şunlardır:

Davranış Kuralları

Angular'ı açık ve kapsayıcı tutmamıza yardımcı olun. Lütfen Davranış Kurallarımızı okuyun ve uygulayın.

Sorunuz mu Var?

GitHub issue'larını hata raporları ve özellik istekleri için kullanmak istediğimizden, genel destek soruları için issue açmayın. Bunun yerine, destekle ilgili sorular sormak için Stack Overflow kullanmanızı öneririz. Stack Overflow'da yeni bir soru oluştururken angular etiketini eklediğinizden emin olun.

Stack Overflow soru sormak için çok daha iyi bir yerdir çünkü:

  • Stack Overflow'da yardım etmeye istekli binlerce kişi var
  • Sorular ve yanıtlar herkese açık kalır, böylece sorunuz/yanıtınız başka birine yardımcı olabilir
  • Stack Overflow'un oylama sistemi en iyi yanıtların öne çıkmasını sağlar.

Zamanınızı ve zamanımızı korumak için, genel destek isteği olan tüm issue'ları sistematik olarak kapatacağız ve kişileri Stack Overflow'a yönlendireceğiz.

Soru hakkında gerçek zamanlı sohbet etmek isterseniz, Angular topluluk Discord sunucusu üzerinden ulaşabilirsiniz.

Bir Hata mı Buldunuz?

Kaynak kodunda bir hata bulursanız, GitHub Deposuna issue göndererek bize yardımcı olabilirsiniz. Daha da iyisi, düzeltmeyle birlikte bir Pull Request gönderebilirsiniz.

Eksik Bir Özellik mi Var?

GitHub Deposuna issue göndererek yeni bir özellik talep edebilirsiniz. Yeni bir özelliği uygulamak istiyorsanız, doğru adımları belirlemek için değişikliğin boyutunu göz önünde bulundurun:

  • Büyük Bir Özellik için önce bir issue açın ve teklifinizi tartışmaya sunun. Bu süreç, çalışmalarımızı daha iyi koordine etmemize, işlerin tekrarlanmasını önlememize ve değişikliğinizin projeye başarıyla kabul edilmesini sağlamamıza yardımcı olur.

    Not: Dokümantasyona yeni bir konu eklemek veya bir konuyu önemli ölçüde yeniden yazmak büyük bir özellik sayılır.

  • Küçük Özellikler doğrudan Pull Request olarak gönderilebilir.

Gönderim Rehberi

Issue Gönderme

Bir issue göndermeden önce lütfen issue takip sistemini arayın. Sorununuz için zaten bir issue olabilir ve tartışma size hazır çözümler sunabilir.

Tüm sorunları mümkün olan en kısa sürede düzeltmek istiyoruz, ancak bir hatayı düzeltmeden önce onu yeniden üretmemiz ve doğrulamamız gerekir. Hataları yeniden üretmek için minimal bir reprodüksiyon sağlamanızı istiyoruz. Minimal bir reprodüksiyon senaryosu, ek sorularla size geri dönmeden bize önemli bilgiler sağlar.

Minimal bir reprodüksiyon, bir hatayı hızlıca doğrulamamızı (veya bir kodlama sorununu tespit etmemizi) ve doğru sorunu düzelttiğimizden emin olmamızı sağlar.

Sürdürücülerin zamanını korumak ve nihayetinde daha fazla hata düzeltebilmek için minimal bir reprodüksiyon istiyoruz. Geliştiriciler genellikle minimal bir reprodüksiyon hazırlarken kodlama sorunlarını kendileri bulurlar. Bazen daha büyük bir kod tabanından temel kod parçalarını çıkarmanın zor olabileceğini anlıyoruz, ancak düzeltmeden önce sorunu gerçekten izole etmemiz gerekiyor.

Ne yazık ki, minimal bir reprodüksiyon olmadan hataları araştıramıyoruz / düzeltemiyoruz, bu nedenle sizden geri dönüş almazsak, yeniden üretilecek yeterli bilgiye sahip olmayan issue'ları kapatacağız.

Yeni issue şablonlarımızdan birini seçerek ve issue şablonunu doldurarak yeni issue açabilirsiniz.

Katkı Kalitesi

Açık kaynak katkısına ve topluluk katkıda bulunanlarından gelen pull request'lere büyük değer veriyoruz. Lütfen her pull request'in ekipteki gerçek bir kişi tarafından incelenip merge edildiğini unutmayın, bu da zaman ve çaba gerektirir. Bu, diğer değerli işlerden alınan zaman ve çabadır. Bunu göz önünde bulundurarak, açılan herhangi bir topluluk katkısı pull request'inden beklenen minimum standartlar belirledik.

  1. Gönderiminizle ilgili açık veya kapalı bir PR için GitHub'da arama yapın.

    • Mevcut çalışmaları tekrarlamak istemezsiniz.

  2. Bir issue veya pull request'in düzelttiğiniz sorunu veya eklemek istediğiniz özelliğin tasarımını açıkça tanımladığından emin olun. Issue'lar minimal bir reprodüksiyon gerektirir.

  3. Bir issue'da tasarımı önceden tartışmak, çalışmanızı kabul etmeye hazır olmamızı sağlar. Pull request'ler tasarım çalışması yapmak için doğru yer değildir.

    • Şüpheye düştüğünüzde, herhangi bir spekülatif uygulama çalışması yapmadan önce bir issue açın

  4. İdeal olarak PR bir issue'ya bağlı olmalıdır, ancak bu zorunlu değildir

  5. Değişiklik, kod kalitesini iyileştirmeli (örneğin bir TODO'yu ele almak) veya bir özelliği etkilemeli / iyileştirmelidir

  6. Mikro optimizasyonlar yalnızca gerçek bir benchmark ile doğrulanırsa kabul edilecektir

  7. "help wanted" etiketli olmayan özellik isteklerini ele alan pull request'ler açmayın çünkü bunlar genellikle pull request'leri kabul edebilmemiz için ek tasarım çalışması gerektirir

  8. Değişiklik iyi test edilmiş olmalıdır

Pull request'iniz bu minimum beklentileri karşılamıyorsa PR'ınızı kapatabiliriz. Ayrıca, PR'ınız breaking change içeriyorsa, bu breaking change'in neden olduğu değişiklik düzeyi ilerleyebilmemizi engelleyebilir. Bu durumda da PR'ınızı kapatabiliriz. Aksi takdirde, katkılarınızı ve Angular'a olan coşkunuzu görmekten heyecan duyuyoruz!

Pull Request (PR) Gönderme

Pull Request (PR) göndermeden önce aşağıdaki kuralları göz önünde bulundurun:

  1. Lütfen PR göndermeden önce Katkıda Bulunan Lisans Sözleşmemizi (CLA) imzalayın. İmzalanmış bir CLA olmadan kodu kabul edemeyiz. Katkıda bulunduğunuz tüm Git commit'lerini CLA imzanızla ilişkili e-posta adresiyle yazdığınızdan emin olun.

  2. angular/angular deposunu fork edin.

  3. Fork edilmiş deponuzda, yeni bir git branch'inde değişikliklerinizi yapın:

    git checkout -b my-fix-branch main

  4. Patch'inizi oluşturun, uygun test case'leri dahil edin.

  5. Kodlama Kurallarımıza uyun.

  6. Geliştirici dokümantasyonunda açıklandığı gibi tam Angular test suite'ini çalıştırın ve tüm testlerin geçtiğinden emin olun.

  7. Commit mesajı kurallarımıza uyan açıklayıcı bir commit mesajıyla değişikliklerinizi commit edin. Bu kurallara uyum gereklidir çünkü release notları bu mesajlardan otomatik olarak oluşturulur.

    git commit --all

    Not: isteğe bağlı --all commit seçeneği, düzenlenen dosyaları otomatik olarak "add" ve "rm" yapacaktır.

  8. Branch'inizi GitHub'a push edin:

    git push origin my-fix-branch

  9. GitHub'da angular:main'e bir pull request gönderin.

Pull Request İnceleme

Angular ekibi, topluluğun iyi vatandaşları olmayan topluluk üyelerinden gelen pull request'leri kabul etmeme hakkını saklı tutar. Bu tür davranışlar, Angular davranış kurallarına uymamayla ilgilidir ve Angular tarafından yönetilen kanalların içinde veya dışında geçerlidir.

İnceleme Geri Bildirimlerini Ele Alma

Kod incelemeleri aracılığıyla değişiklik istersek:

  1. Kodda gerekli güncellemeleri yapın.

  2. Testlerin hâlâ geçtiğinden emin olmak için Angular test suite'lerini yeniden çalıştırın.

  3. Bir fixup commit oluşturun ve GitHub deponuza push edin (bu Pull Request'inizi güncelleyecektir):

    git commit --all --fixup HEAD
git push

    Fixup commit'lerle çalışma hakkında daha fazla bilgi için buraya bakın.

İşte bu kadar! Katkınız için teşekkürler!

Commit Mesajını Güncelleme

Bir incelemeci genellikle commit mesajında değişiklikler önerebilir (örneğin, bir değişiklik için daha fazla bağlam eklemek veya commit mesajı kurallarımıza uymak için). Branch'inizdeki son commit'in mesajını güncellemek için:

  1. Branch'inize geçin:

    git checkout my-fix-branch

  2. Son commit'i amend edin ve commit mesajını değiştirin:

    git commit --amend

  3. GitHub deponuza push edin:

    git push --force-with-lease

NOT:
Daha eski bir commit'in mesajını güncellemeniz gerekiyorsa, git rebase'i interaktif modda kullanabilirsiniz. Daha fazla ayrıntı için git dokümantasyonuna bakın.

Pull Request'iniz Merge Edildikten Sonra

Pull request'iniz merge edildikten sonra branch'inizi güvenle silebilir ve ana (upstream) depodan değişiklikleri çekebilirsiniz:

  • GitHub web arayüzü veya yerel shell'iniz aracılığıyla uzak branch'i silin:

    git push origin --delete my-fix-branch

  • Main branch'e geçin:

    git checkout main -f

  • Yerel branch'i silin:

    git branch -D my-fix-branch

  • Yerel main'inizi en son upstream sürümüyle güncelleyin:

    git pull --ff upstream main

Kodlama Kuralları

Kaynak kodu genelinde tutarlılık sağlamak için, çalışırken şu kuralları aklınızda tutun:

Commit Mesajı Kuralları

Git commit mesajlarımızın nasıl formatlanacağına dair çok kesin kurallarımız var:

<type>(<scope>): <kısa özet>

Ayrıntılar için Commit Mesajı Kurallarına bakın.

CLA İmzalama

Lütfen pull request göndermeden önce Katkıda Bulunan Lisans Sözleşmemizi (CLA) imzalayın. Herhangi bir kod değişikliğinin kabul edilmesi için CLA imzalanmış olmalıdır. Hızlı bir süreç, söz veriyoruz!

Birden fazla GitHub hesabınız veya tek bir GitHub hesabıyla ilişkili birden fazla e-posta adresiniz varsa, Git commit'lerini yazmak ve pull request göndermek için kullandığınız GitHub hesabının birincil e-posta adresiyle CLA'yı imzalamanız gerekir.

Aşağıdaki belgeler, GitHub hesapları ve birden fazla e-posta adresiyle ilgili sorunları çözmenize yardımcı olabilir: