Açık kaynağa katkı nasıl yapılır? İlk merge edilen PR'ına kadar

GitHub'da "good first issue" etiketli bir iş buldun, açtın. Altında üç yorum var, üçü de "Bunu ben alabilir miyim?" diyor. En sonuncusu iki ay önce yazılmış. Kimse PR göndermemiş, bakımcı da cevap vermemiş. Ne yapacaksın?

Açık kaynağa ilk katkının zor kısmı genelde kodu yazmak değil; doğru projeyi, doğru işi ve doğru iletişim biçimini bulmak. Bu yazı kod kısmıyla birlikte o kısımları da anlatıyor.

Önce projeyi seç, sonra işi

İlk katkı için en iyi aday, zaten kullandığın bir araç ya da kütüphane. Nasıl davrandığını kullanıcı olarak biliyorsun, hatayı nerede arayacağını kestirebilirsin.

Bir projenin yeni katkıcıya uygun olup olmadığını anlamak için şunlara bak:

• Hâlâ yaşıyor mu? Son commit ne zaman atılmış? Açık PR'lara bakımcılar cevap veriyor mu, yoksa aylardır bekleyen onlarca PR mı var?
• CONTRIBUTING.md var mı? Katkı rehberi olan projeler yeni gelenleri bekliyor demektir. Bu dosya projeyi nasıl kuracağını, testleri nasıl çalıştıracağını ve PR'dan ne beklendiğini anlatır.
• Davranış kuralları (code of conduct) var mı? Topluluğun yeni gelenlere nasıl davrandığı hakkında fikir verir.
• Review'ların tonu nasıl? Birkaç kapanmış PR'ı açıp yorumları oku. Sabırlı ve açıklayıcı bir dil iyi bir işaret.

"Good first issue" nerede bulunur?

• Projenin kendi sayfası: Birçok repoda github.com/SAHIP/REPO/contribute adresi "good first issue" etiketli işleri listeler. Issues sekmesinde etikete göre filtrelemek de aynı sonucu verir.
• GitHub araması: is:issue is:open label:"good first issue" language:python gibi bir sorguyla etiket ve dile göre arama yapabilirsin.
• Derleme siteler: goodfirstissue.dev ve up-for-grabs.net, yeni katkıcılara uygun işleri proje proje toplar.
• Prova turu: Hiç PR açmadıysan firstcontributions/first-contributions reposu fork'tan PR'a kadar bütün akışı güvenli bir ortamda denemeni sağlar. README'sinin Türkçe çevirisi de var.

Etiketi körü körüne takip etme. Etiket bir ipucu, garanti değil. Issue'yu oku; ne istendiğini anlamadıysan o iş şimdilik senin işin değil.

Katkı her zaman kod değildir

• Dokümantasyondaki eksik ya da yanlış bir adımı düzeltmek
• Bir hatayı yeniden üretip adımlarıyla raporlamak
• Eksik bir örnek ya da test eklemek
• Proje kabul ediyorsa belgelerin çevirisine yardım etmek

Kurulum rehberini takip ederken takıldığın yer, büyük ihtimalle başkalarının da takıldığı yer. Onu düzelten bir PR, ilk katkı için çok iyi bir başlangıç.

Başlamadan önce issue'ya yaz

Kod yazmadan önce issue'nun altına kısa bir yorum bırak:

Merhaba, bu işi almak isterim. Sorunun tarih ayrıştıran fonksiyonda boş metin geldiğinde oluştuğunu düşünüyorum; hata fırlatmak yerine boş değer döndürmeyi planlıyorum. Bu yaklaşım uygun mu?

Bu yorum üç şey yapar: işi aldığını duyurur, problemi anladığını gösterir ve bakımcıya yön düzeltme şansı verir. Bazı projeler işi resmen atamadan PR kabul etmez; bunu CONTRIBUTING.md'den kontrol et.

Yazının başındaki durumdaysan, yani eski "ben alabilir miyim?" yorumları var ama PR yoksa, kibarca sor: "Bu iş hâlâ açık mı? Kimse çalışmıyorsa almak isterim."

Fork, clone, branch

Açık kaynak projelerde genelde ana repoya yazma yetkin olmaz. Bu yüzden önce GitHub'da repoyu forklarsın, yani kendi hesabına bir kopyasını alırsın. Sonra:

git clone https://github.com/KULLANICI_ADIN/proje.git
cd proje
git remote add upstream https://github.com/SAHIP/proje.git
git fetch upstream
git switch -c bos-tarih-hatasi upstream/main

Burada origin senin fork'un, upstream ise asıl proje. Branch'i doğrudan upstream/main'den açmak, en güncel kodun üstünde çalışmanı sağlar. Projenin varsayılan branch'i main değilse (örneğin master ya da develop) komutu ona göre değiştir.

Değişiklikten önce testleri çalıştır

CONTRIBUTING.md'deki kurulum adımlarını uygula ve hiçbir şeyi değiştirmeden testleri bir kez çalıştır. Böylece sonradan kırmızıya dönen bir testin senin değişikliğinden mi, yoksa zaten bozuk olduğundan mı kaynaklandığını bilirsin.

Değişikliği küçük ve odaklı tut

• Sadece issue'nun istediğini yap. Yolda gördüğün başka sorunlar için ayrı issue aç.
• Projenin kod stiline uy. Dosyanın tamamını kendi editör ayarlarınla yeniden biçimlendirirsen reviewer gerçek değişikliği göremez.
• Bir hatayı düzelttiysen, o hatanın geri gelmeyeceğini gösteren bir test ekle.
• Anlamadığın kodu gönderme. Bir araca ürettirdiğin değişikliği satır satır anlamadan ve kendin test etmeden PR açmak bakımcının zamanını harcar ve genelde kolayca fark edilir.

Pull request'i aç

git add -p
git commit -m "Boş tarih değerinde hata yerine boş sonuç döndür"
git push -u origin bos-tarih-hatasi

GitHub'da fork'unun sayfasına gittiğinde asıl projeye PR açma önerisi çıkar. Açıklamada:

• Neyi neden değiştirdiğini anlat.
• Fixes #123 ile issue'yu bağla. PR projenin varsayılan branch'ine merge edildiğinde issue otomatik kapanır.
• Nasıl test ettiğini yaz.
• Projenin bir PR şablonu varsa eksiksiz doldur.

Bazı projeler katkıdan önce bir katkıcı lisans anlaşması (CLA) imzalamanı ister. Bazıları ise her commit'te git commit -s ile eklenen "Signed-off-by" satırını (DCO) bekler. Genelde PR'ı açtığında otomatik bir kontrol bunu sana söyler.

Review sürecinde sabırlı ol

Bakımcıların çoğu bu işi gönüllü olarak ya da asıl işlerinin yanında yapıyor. Cevap birkaç gün, bazen birkaç hafta sürebilir. Bir hafta sessizlik olduysa tek bir kibar hatırlatma yeterli.

Değişiklik istenirse aynı branch'te düzelt ve push et; PR kendiliğinden güncellenir. Bu arada asıl projede main ilerlediyse branch'ini güncelle:

git fetch upstream
git rebase upstream/main
git push --force-with-lease

PR'ın kapatılabilir de. Proje yön değiştirmiş, başka biri aynı sorunu çözmüş ya da bakımcı farklı bir yaklaşım istiyor olabilir. Bu kişisel değil. Kapatılma nedenini oku ve bir sonraki katkında ondan yararlan.

Merge edildikten sonra

İlk PR'ın merge edildiğinde iki şey kazanırsın: profilinde görünen gerçek bir katkı ve seni artık tanıyan bir bakımcı.

Aynı projede ikinci ve üçüncü katkıyı yapmak ilkinden çok daha kolaydır, çünkü kod tabanını ve beklentileri artık biliyorsun. Rastgele projelere tek seferlik katkılar yerine bir iki projede derinleşmek hem daha çok şey öğretir hem de iş başvurularında daha güçlü bir referans olur.

Açık kaynakta daha düzenli çalışmak istersen Google Summer of Code gibi programlara da bakabilirsin. Program 18 yaşını doldurmuş öğrencilere ve açık kaynakta yeni olanlara açık; katılımcılar bir açık kaynak organizasyonunda mentorlarla birlikte bir proje yürütüyor.

Son söz

İlk PR'ı tek başına açmak gergin olabilir. Yanında açıklamanı okuyup "bu yeterince net mi?" diyebileceğin biri olunca iş kolaylaşıyor. Benzer şeyleri birlikte denemek istersen re:make her pazar 15.00'te Buca'da buluşuyor; yeri ve saati burada. Ekim ayındaysan Hacktoberfest 2026 yazımıza da göz at, bu yıl kurallar değişti.