Açık Kaynak Kodlu Yazılımlara Yeni Katkıda Bulunanların Sık Yaptığı 7 Hata

Açık kaynak kodlu yazılımlara katkıda bulunmak, toplulukta bir fark yaratmak ve bir ekipte nasıl çalışılacağını öğrenmek için harika bir yoldur. Bir açık kaynak bakımcısı olarak, yeni katılımcılarla çalışmayı ve topluluğun olumlu bir şekilde büyüdüğünü görmeyi seviyorum. Ancak açık kaynak projelerine daha fazla dahil olmaya başladıkça, yeni katkıda bulunanlar tarafından yapılan birkaç yaygın hatayı fark ettim.

Bu blog yazısında, açık kaynaklı projelere yeni katkıda bulunanlar tarafından yaygın olarak yapılan 7 hatanın üzerinden geçeceğim.

İçerik tablosu

• Katkıda bulunan belgelerin göz ardı edilmesi
• Mevcut olmayan konuların toplanması
• İncelemelerden önce kendi çalışmalarını gözden geçirmemek
• Talep edilmeyen özellikler için PR oluşturma
• Tanımlayıcı olmayan konular oluşturma
• Açıklayıcı olmayan PR başlıkları oluşturma
• Çekme isteği ve sorun şablonlarını yok sayma
• Sonuç

Katkıda bulunan belgelerin göz ardı edilmesi

Katkıda bulunan belgelerin amacı, yeni bir projeye katkıda bulunmak isteyen geliştiricilere yardımcı olmaktır. Güçlü açık kaynak projeleri, aşağıdaki öğeleri içerecek şekilde iyi tanımlanmış katkı belgelerine sahip olacaktır:

• Proje yerel olarak nasıl kurulur
• Mesaj kurallarını taahhüt eder
• İstek yönergelerini çekecektir
• Kabul edi̇lecek katki türleri̇

Tüm geliştiricilerin bu belgeleri okuması önemlidir, böylece bakımcıların ne aradığını anlayacaklardır. Katkıda bulunma belgelerini atlarsanız, muhtemelen ihtiyaç duyulmayan veya talep edilmeyen bir PR oluşturursunuz. Bu da genellikle bakımcıların PR’yi kapatmak zorunda kalmasına neden olur.

Katkıda bulunmak istediğiniz bir proje bulursanız, lütfen README ve katkı belgelerini okumak için zaman ayırın. Herhangi bir sorunuz varsa, bakımcılara ulaşın, size yardımcı olmaktan mutluluk duyacaklardır.

Mevcut olmayan konuların toplanması

Hacktoberfest sırasında karşılaştığım sorunlardan biri, geliştiricilerin zaten başka birine atanmış olan sorunları almalarıydı. Bu katılımcı daha sonra bir PR açıyor ve bir inceleme talep ediyordu, bu da benim onu kapatmamla sonuçlanıyordu.

Yeni başlayan biri olarak bazen üzerinde çalışabileceğiniz konular bulmanın zor olduğunu anlıyorum. Ancak konu mevcut değilse, bakımcıların konuya atanmış başka biri yerine PR’nizi kabul edeceğini umarak üzerinde çalışmaya başlamayın.

İncelemelerden önce kendi çalışmalarını gözden geçirmemek

Hacktoberfest sırasında depoların bakımını yaparken fark ettiğim şeylerden biri, yeni başlayanların çoğunun inceleme için gönderdikleri PR’ye bakmadıklarıydı. Çok sayıda yazım hatası, sözdizimi hatası ya da test edilmemiş veya doğru çalışmayan özellikler buldum.

Bir bakım sorumlusundan inceleme talep etmeden önce, kendi çalışmanız üzerinde hızlı bir inceleme yaptığınızdan ve bu değişiklikleri yerel olarak çalıştırdığınızdan emin olun. Başlangıçta bir sorun üzerinde çalışırken yanlışlıkla gözden kaçan hataların ve hataların miktarına şaşıracaksınız. Ancak PR’ye ikinci kez bakmak bu hataları bulmanıza ve PR’yi daha da iyi hale getirmenize yardımcı olabilir.

Talep edilmeyen özellikler için PR oluşturma

Bir bakımcı olarak, projeye eklemek istemediğimiz özellikler için PR oluşturan birkaç geliştirici örneği vardı. Bu geliştiriciler iyi niyetliydi ancak ne yazık ki kapatılan katkılar yaparak zamanlarını boşa harcadılar.

Bir özellik için yeni bir fikriniz varsa, lütfen üzerinde çalışmaya başlamayın ve bir PR oluşturmayın. Bunun yerine özellik isteğiniz için yeni bir sorun oluşturmalısınız. Bu noktada, bir bakım görevlisi size geri dönecek ve özelliğinizle devam etmek isteyip istemediklerini size bildirecektir.

Tanımlayıcı olmayan konular oluşturma

Bir sorun oluştururken mümkün olduğunca fazla ayrıntı vermeniz önemlidir, böylece bakımcılar size en iyi nasıl yanıt vereceklerini bilirler. Örneğin, sitede bir hata bulursanız, hatanın nasıl yeniden üretileceğine ilişkin ayrıntıların yanı sıra uygun olduğunda bağlantılar, ekran görüntüleri veya videolar eklediğinizden emin olun. Bu, bakımcıya sorunu giderme ve bir sonraki en iyi eylem planının ne olduğunu belirleme fırsatı verecektir.

Açıklayıcı olmayan PR başlıkları oluşturma

Bir bakımcı olarak en çok karşılaştığım sorunlardan biri belirsiz ve genel başlıklara sahip PR’lardır. “Benioku’yu güncelleme” veya “Hatayı düzeltme” gibi başlıklar, bakım sorumlusunun PR’nizle neyi başarmaya çalıştığınızı anlamasına yardımcı olmaz. Yapmak istediğiniz değişiklikleri etkili bir şekilde ileten kısa açıklayıcı başlıklara sahip olmanız önemlidir.

Çekme isteği ve sorun şablonlarını yok sayma

Birçok açık kaynak projesi, katkıda bulunanların gerekli tüm bilgileri sağlamasına yardımcı olmak için sorun ve PR şablonlarına sahip olacaktır. Sorun şablonları genellikle Hatalar, Özellikler, Dokümantasyon vb. gibi farklı kategorilere ayrılır. Bir katılımcı olarak, uygun sorun şablonunu seçmeniz ve gerekli tüm alanları doldurmanız önemlidir, böylece bakımcılar size nasıl yardımcı olacaklarını bilirler.

İşte PR şablonuna bir örnek:

# Açıklama

<!– Lütfen yapılan değişikliklerin ayrıntılı bir özetini ekleyin. Ayrıca lütfen bu PR’nin düzelttiği sorunun bağlantısını verin. –>

Düzeltmeler # (sorun)

<!– Lütfen bu PR için değişiklik türünü seçmek üzere [ ] içine bir x işareti koyun. –>

## Değişim türü

– [ ] Hata düzeltme (bir sorunu düzelten, kırıcı olmayan değişiklik)

– [ ] Yeni özellik (işlevsellik ekleyen, kırıcı olmayan değişiklik)

– [ ] Kırıcı değişiklik (mevcut işlevselliğin beklendiği gibi çalışmamasına neden olacak düzeltme veya özellik)

– [ ] Görev öğeleri (bu, dosyaların temel temizliğini veya paketlerdeki güncellemeleri içerir)

– [ ] Dokümantasyon güncellemeleri

<!– Lütfen inceleme talebinde bulunmadan önce kontrol listesinin tamamını gözden geçirdiğinizden emin olun. Tamamlanan tüm maddeleri işaretlemek için [ ] içine bir x işareti koyun –>

## Kontrol Listesi

– [ ] PR’ım için açıklayıcı bir başlığım var

– [ ] Sorunu bu [PR] ile ilişkilendirdim

– [ ] Projeyi yerel olarak çalıştırdım ve kod değişikliklerini gözden geçirdim

– [ ] Yaptığım değişiklikler yeni uyarılar oluşturmuyor

 

Sonuç

Açık Kaynak yazılımına dahil olmak, bir ekipte çalışmaya başlamak ve gerçek dünya projelerine anlamlı bir şekilde katkıda bulunmak için harika bir yoldur. Açık kaynakla öğrenilecek çok şey olsa da, lütfen yeni katkıda bulunanlar tarafından yaygın olarak yapılan bu 7 hataya dikkat edin.

 

Açık kaynakta yaygın olarak yapılan başka hatalarınız varsa, lütfen aşağıdaki yorumlar bölümünde yanıtlayın.

 

Mutlu kodlamalar!