dotcode podcast — “Open Source Projelere Nasıl Katkıda Bulunulur?”
Herkese Merhaba,
bu yazımda Berkan Şaşmaz ile birlikte açtığımız yeni podcast kanalının (dotcode), üçüncü bölümünde konuştuğumuz “Open Source Projelere Nasıl Katkıda Bulunulur?” konusuna hazırlanırken çıkardığım notlardan bahsediyor olacağım.
Bu makaleyi yazdığım tarih itibariyle (16/04/2023), üç bölüm yayınlanmış durumda. Diğer bölümler ile ilgili yazılara aşağıdaki linklerden ulaşabilirsiniz:
Bu bölüm için hazırlanırken birkaç maddeden oluşan notlar çıkardım. Kendi tecrübe ettiğim şeyleri listelemek ve bunları bir makale içinde sizlerle paylaşmak istedim.
Açık Kaynaklı Yazılım (OSS) Nedir?
Konuya giriş yapmadan önce, OSS’in ne olduğunu kısaca bir hatırlamakta fayda var:
Bir projenin kaynak kodlarının kullanımı, değiştirilmesi ve dağıtılmasına izin verilmesidir, daha net bir tabirle kullanıma açık tutulmasıdır. Bu kaynak kodlarının kullanılması ve dağıtılmasını belirli bir kural altında belirlemek için MIT gibi lisanslar kullanılarak, bu sınırlar belirtilir.
OSS mentalitesi bize bir çok fayda sağlıyor. En temel fayda olarak, insanların birbirlerinin geliştirdikleri projeleri görebilmesi ve inceleyerek geliştirebilmesi veya ondan esinlenebilmesini ve bu sayede de genel olarak yazılım kalitesinin gelişmesine katkı sağlar.
Aynı zamanda, birden fazla kişi bir proje vizyonunda ortak özellikler geliştirebiliyorlar ve belki de en önemli noktalarından birisi kullanılan projelerin ölmesi veya diğer bir tabirle kullanım dışı kalması gibi bir durum söz konusu değil. Projeler arşivlenip geliştirilmesi sonlandırılsa veya proje adı ve şartları değişip ücretli hala gelebilse bile genel yapı ve mentalite bu şekilde.
Neden OSS Bir Projeye Katkı Sağlamak İsteyelim? Katkıları Nelerdir?
Bence en temel katkısı bizi geliştirmesi, yeni kodlar ve tasarımlar görerek kendi yazılım seviyemizi bir üst seviyeye taşımaya yardımcı olmaları. Sonuçta hemen hemen herşey gibi yazılımda iterative bir süreç ve adım adım bir gelişim mevcut. Bu noktada bu tarz projeleri inceleyip, yapısını anlamak ve katkıda bulunmaya çalışmak birçok fayda sağlıyor.
Van Gogh’un sevdiğim çok güzel bir sözü var: “Harika şeyler, küçük parçaların bir araya gelmesi ile oluşur.” bu söz de aslında güzel bir mentalite sağlıyor bize, kullandığımız projeleri geliştirmek ve bulduğumuzdan daha iyi bir hale getirmek. Bu hem kişisel hemde mesleki tatmin ve gelişim açısından çok önemli!
Aynı zamanda, iyi tasarlanmış bir projeyi inceleyerek, yazılım sektöründeki iyi geliştiricilerin kodlarını incelemek ve o noktalardan gerekli yazılım geliştirme yaklaşımları öğrenmekte işin bir diğer güzel tarafı.
Bir Projeye Katkıda Bulunmaya Karar Vermeden Önce Nelere Dikkat Etmek Gerekiyor?
Bir OSS’ye katkıda bulunma diyince aklımıza sadece kod gelmemeli. Dökümanları gözden geçirebiliriz, bulduğumuz typoları düzeltebiliriz, issue oluşturup hata bildirebiliriz vs.
Katkıda bulunmak için amacımızın bir sorunu çözmek veya yeni bir özellik eklemek olması gerekiyor. Bunu yapabilmek için katkıda bulunacağımız projeyi daha önceden kullanmak ve mantığını algılamak önemli.
Yani, birden durup ben gidip elasticsearch ün repository sine katkıda bulunmalıyım diye düşünmek ve bununla ilgili adım atmak çok realist bir bakış açısı değil bence. Bunun yerine sıklıkla kullandığımız, kullanırken şu olsa çok işime yarar dediğimiz veya burada bir hata var dediğimiz noktalara yoğunlaşmamız çok daha realist ve doğru bir yaklaşım bence.
Bu sayede bizimle benzer sorunlarla veya isteklerle karşılaşan kişilere de yardımcı olmuş olacağız ve gerçek anlamda bir katkı sağlamış olacağız.
Yani, toparlayacak olursam katkı sağlamadan önce ilgili projeyi kullanmak veya en azından yapısını bilmek, dökümanlarında gezinmek çok önemli ve doğru olan yaklaşım bu bence.
Contributing.md, Code of Conduct Vb. Önemli Belgeler
- Contributing.md dosyası, projemize katkıda bulunmak isteyen kişilere yapması gereken şeyleri belirttiğimiz bir dosya. Katkıda bulunmak için ne yapmaları gerekiyor, beklentilerimiz neler (code coverage olabilir, ilk issue açıp gelen sonuca göre iş ataması olabilir veya çok daha farklı şeyler olabilir) vb. konuları anlatıyoruz.
- Code of conduct, bir projeye katkıda bulunacak kişilerden beklenen davranışın, adaptasyon aşamalarının ve ilgili topluluk ile nasıl bir uyum içinde çalışılabileceğinin anlatıldığı bir dosyadır. Genel olarak topluluk kuralları olarak düşünülebilir. Koddan bağımsız olarak tarafları korumak için oluşturulan bir belgedir.
- Bu iki dosya gibi kullanılan bir çok farklı “katkı sağlama aşamalarını anlatan dökümanlar” mevcut, ama temel olarak bu 2 dosyaya ve README.md dosyasına katkı sağlamadan önce göz atmak lazım diye düşünüyorum.
Nasıl Issue Bulabiliriz?
Issue bulmamız için bize yardımcı olan labellar mevcut, genel olarak “help wanted”, “good first issue” ve “up-for-grabs” bunlara örnek. Bu label ile işaretli issuelar genellikle başlamak için ideal olan ve ele alarak tamamlayabileceğiniz işleri içeriyor.
Kullandığınız projeler de bu label a sahip issuelara göz atabilirsiniz.
Bunun dışında genel olarak katkı sağlamak istiyorsanız, bunun içinde güzel siteler var. Birçok projeyi label bazlı olarak sıralayan sitelerden bahsediyorum. Örneğin https://goodfirstissue.dev/ sitesine gidip “good first issue” labelına sahip popüler repository’leri görüp oradan issue seçerek katkı sağlamaya başlayabilirsiniz.
Katkıda Bulunurken Yapılması Gerekenler Neler?
Bir projede bir sorun olduğunu gördük veya özellik önerimiz var veya dökümantasyonda birşey bulduk diyelim bu durumda ne yapmamız lazım.
İlk olarak “Contributing.md” dosyası varsa bu dosyayı incelememiz gerekiyor.
Bu döküman bize genel olarak yol gösterecektir ama genel olarak ilk yapacağımız şey, bulduğumuz sorunla veya özellik önerisi ile ilgili bir issue oluşturmak olacaktır. Tabii issue oluşturmadan önce hali hazırda bu konu ile ilgili bir issue açık mı onu kontrol etmeliyiz.
Daha sonra, projenin aktif geliştiricilerinden bir geri bildirim bekleyerek ona göre ister kendimiz istersekte bir başkasının projeye geliştirme yapması sağlanabilir.
Aynı şekilde ilgili issue hali hazırda açık ise, üzerinde çalışan birinin olmadığına emin olup ondan sonra başlamak lazım bu da çok önemli bir adım! Aksi takdirde gereksiz yere 2 kişi aynı iş üzerinde çalışıyor olabilir.
Yani temel olarak ilk adım “İletişim/koordinasyon” aşaması olmalı.
Ona göre daha sonra branch oluşturup iş üzerinde çalışmaya başlayabiliriz. Branch oluşturma durumunda ilk olarak ilgili projenin git-flow u hakkında da bilgi sahibi olmalıyız, nasıl bir branching yaklaşımı var bunu anlamalıyız. Bu genelde README.md ve CONTRIBUTING.md dosyalarında anlatılıyor zaten, oradan yararlanabiliriz.
Burada branch oluşturup bir geliştirme yapmaya direkt başlamadan önce, projenin entry pointlerini inceleyip en azından kendi localimizde çalıştırabilmeliyiz, testler varsa onları çalıştırıp herhangi bir sorun olmadığından emin olarak ilerlemeliyiz.
Bu projenin büyüklüğü ve karmaşıklığına göre çok zor bir hal alabilir. Örneğin, meraktan dotnet runtime repository sini açıklamalara göre çalıştırıp, testlerini çalıştırmayı denediğimi ve bunda gerçektende çok zorlandığımı hatırlıyorum.
Ama bir katkı sağlamadan önce ne kader zorda olsa bu kesinlikle yapılması gereken bir adım.
Çünkü aksi takdirde gelişmeyi yapsak bile bunu test edememiş olacağız ve bir anlamı kalmamış olacak. O yüzden bu çok önemli!
Daha sonra entry pointlerden başlayarak sistemin genel yapısını incelemeli, mantığını anlamalı ve ona göre geliştirme yapmalıyız.
Yani geliştirme aşamasından önce → kodun derlenip, çalıştırılıp aynı zamanda testlerinde çalıştırılıp, kodların genel yapısı incelenip ondan sonra aksiyona geçmek lazım.
İlgili podcast bölümü şuan 4 platformda yayında ve aşağıdaki linklerden ulaşabilirsiniz:
Sosyal medya hesaplarından da bizi takip etmeyi unutmayın, böylece yeni bölümler hakkında hızlı bir şekilde haberdar olabilirsiniz:
Okuduğunuz için teşekkürler, umarım keyif almışsınızdır. Bir sonraki yazı da görüşmek üzere…
