Açık kaynak projeye ilk katkınızı nasıl yaparsınız?

Katkı yalnızca kod yazmak mıdır?

Hayır. Açık kaynak projelerin sağlıklı kalması için kod dışında da çok iş vardır: dokümantasyondaki hataları düzeltmek, örnekler eklemek, çeviri yapmak, hata raporlarını yeniden üretmek ve doğrulamak, kullanıcı sorularını yanıtlamak, test eklemek. Çoğu bakımcı için iyi yazılmış bir hata raporu ya da netleştirilmiş bir belge, aceleyle yazılmış bir kod değişikliğinden daha değerlidir.

Bu önemlidir çünkü ilk katkı için büyük bir özellik hedeflemek çoğu zaman cesaret kırar. Küçük bir yazım düzeltmesi bile sizi sürecin tamamından geçirir: depoyu çatallama, dal açma, değişiklik yapma, PR gönderme, geri bildirim alma. Bu akışı bir kez yaşadıktan sonra daha büyük işlere geçmek çok daha kolaylaşır.

Uygun bir proje nasıl seçilir?

Gerçekten kullandığınız ya da merak ettiğiniz bir proje seçin; kullandığınız bir kütüphanedeki eksik belge veya karşılaştığınız bir hata iyi bir başlangıçtır. Seçimde şu işaretlere bakın:

• Depoda yakın zamanda işlem ve yanıt var mı
• README, CONTRIBUTING (katkı rehberi) ve CODE_OF_CONDUCT (davranış kuralları) dosyaları var mı
• Açık issue'larda "good first issue" ya da "help wanted" gibi etiketler var mı
• Gelen PR'lara bakımcılar yanıt veriyor mu
• Test ve geliştirme ortamı kurulumu belgelenmiş mi

CONTRIBUTING dosyası en önemli kaynaktır. Kod stilini, test çalıştırma yöntemini, PR beklentilerini ve bazen önce issue açma zorunluluğunu burada bulursunuz. Bu dosyayı okumadan açılan PR'ların çoğu, kurallara uymadığı için düzeltme istenerek geri döner.

Fork, clone ve upstream kurulumu

Başkasının deposuna doğrudan yazma izniniz olmadığı için önce kendi hesabınıza bir kopya çatallarsınız (fork). Sonra bu kopyayı bilgisayarınıza klonlarsınız ve orijinal depoyu ek bir uzak depo olarak eklersiniz:

git clone https://github.com/kullanici/proje.git cd proje git remote add upstream https://github.com/orijinal-sahip/proje.git git fetch upstream

Burada origin sizin çatalınızı, upstream orijinal projeyi gösterir. Çalışmaya başlamadan önce ve zaman zaman yerel ana dalınızı upstream ile eşitleyin; böylece eski bir tabana göre çalışmazsınız. Katkı yapacağınız her iş için ana dalda değil, yeni bir dalda çalışın: git switch -c duzelt/readme-yazim-hatasi. Bu, birden fazla katkıyı birbirinden bağımsız tutar.

Değişikliği yapmak, test etmek ve işlemek

Önce projenin yerel geliştirme ortamını belgelerine göre kurun ve mevcut testleri çalıştırın; değişiklikten önce testlerin geçtiğini görmek, kendi değişikliğinizin neyi bozduğunu ayırt etmenizi sağlar. Sonra değişikliği küçük ve odaklı tutun: bir PR bir şey yapsın. Projenin kod stiline ve biçimlendirme kurallarına uyun; birçok proje bunu otomatik denetler.

Kod değişikliği yapıyorsanız ilgili testi ekleyin ya da güncelleyin. İşleme mesajını projenin biçimine uygun yazın; bazı projeler özel bir mesaj kuralı ya da "geliştirici kaynak sertifikası" imzası (sign-off) ister. Bunlar CONTRIBUTING dosyasında yazar. Bitirince değişiklikleri çatalınıza gönderin: git push origin duzelt/readme-yazim-hatasi. Gönderim sonrası GitHub, orijinal depoya PR açma önerisi sunar.

Pull request'i nasıl açar ve yönetirsiniz?

PR açıklamasında neyi, neden değiştirdiğinizi ve nasıl test ettiğinizi açıkça yazın. İlgili bir issue varsa bağlayın. Proje bir PR şablonu sunuyorsa doldurun. Büyük bir değişiklik öneriyorsanız, kod yazmaya başlamadan önce issue açıp yaklaşımı bakımcılarla konuşmak emek kaybını önler; reddedilecek bir özellik üzerinde günlerce çalışmak sık görülen bir hayal kırıklığıdır.

PR açıldıktan sonra sabırlı olun. Bakımcılar çoğunlukla gönüllüdür ve yanıt günler sürebilir. Otomatik kontroller (CI) başarısız olursa nedenini siz inceleyin ve düzeltin. Geri bildirim geldiğinde savunmacı olmayın; istenen değişiklikleri aynı dala işleme olarak ekleyin, PR otomatik güncellenir. Bakımcı geçmişin temizlenmesini isterse interactive rebase ya da squash gerekebilir. Birleşme sonrası upstream'i çekip çatalınızı eşitleyin.

Bakımcılarla iletişim ve davranış kuralları

Açık kaynak topluluklarında iletişim yazılıdır ve çoğu zaman farklı kültür ve dillerden insanlar arasındadır. Net, kibar ve kısa yazın. Bir hata bildirirken sürümü, ortamı, yeniden üretme adımlarını ve beklenen ile gerçekleşen davranışı belirtin. Soru sorarken önce belgeleri ve mevcut issue'ları arayın.

Bir PR ya da öneri reddedilirse bunu kişisel almayın; bakımcının projenin yönünü ve bakım yükünü gözettiğini hatırlayın. Davranış kurallarına uymak zorunludur. Aynı zamanda lisansı anlayın: katkınız projenin lisansı altında dağıtılır ve işvereninizin çalışma sözleşmesi dışarıya katkıyı kısıtlıyor olabilir. İş yerinde kullandığınız bir projeye katkı yapmadan önce şirket politikasını kontrol edin.

Sık yapılan hatalar ve büyüme yolu

Sık hatalar: CONTRIBUTING dosyasını okumamak, devasa ve çok amaçlı PR göndermek, önce tartışmadan büyük değişiklik önermek, ana dalda çalışmak, testleri çalıştırmamak ve geri bildirime yanıt vermeyip PR'ı terk etmek. Bir de başkasının üzerinde çalıştığı issue'yu sormadan almak yaygın bir kabalıktır; önce issue'ya yorum yazıp çalışmak istediğinizi belirtin.

İlk katkıdan sonra yol doğal biçimde genişler: önce belge ve küçük düzeltmeler, sonra etiketli kolay hatalar, ardından kendi alanınıza giren özellikler. Düzenli katkı verenler zamanla inceleme yetkisi ve bakımcılık rolü kazanabilir. Katkı geçmişiniz GitHub profilinizde herkese açık bir portföy olarak da görünür; gerçek bir ekip yapısında çalışma deneyimini kanıtlar.

Bu beceri Mindset programlarında nerede çalışılır?

Mindset'in GIT ve GITHUB Uzmanlığı Eğitimi, Git'e giriş, branch yönetimi ve merge işlemleri, GitHub ile işbirliği ve proje yönetimi, ileri düzey Git teknikleri ve ayrıca Open Source Katkı Süreçleri başlıklarını içerir. Açık kaynak katkı süreçleri bölümü, bu sayfada anlatılan fork, PR ve topluluk iletişimi akışını Git bilgisinin üzerine oturtur. Eğitim, açık kaynak deneyimi kazanmak isteyen geliştiricilere ve ekibinin dış projelere katkı politikasını belirleyen teknik liderlere uygundur.

Kurumsal ekipler için bu bilgi, şirketin kullandığı açık kaynak bileşenlerde karşılaştığı hataları geri bildirme ve düzeltme katkısı olarak yönetmesine yardımcı olur.