C3: Bir OSS projesine 1 PR

Ebeveyn / Mentor Notu

Bu capstone gerçek bir GitHub hesabı ve gerçek bir PR içerir. Bir ebeveyn veya öğretmen yanında olsun:

• GitHub hesabı açılırken e-posta, kullanıcı adı, bio seçiminde yardım.
• Açık kaynak topluluklarının iletişim normları (İngilizce, kısa ve net, sabırlı).
• Kişisel bilgi paylaşımı (lokasyon, okul, doğum yılı) minimumda tutulmalı.
• PR review aşaması duygusal olabilir — reddedilince motivasyon kırılır; destek olun.

Süreç pedagojik değer taşır; aktif katılın, her adımı beraber konuşun.

OSS PR’ı Neden İşe Alımda Altın?

Bir veri mühendisi adayının portfolyosunda 3 öğe olmalı:

1. Kendi projesi — uçtan uca pipeline (C1).
2. Veri kalitesi aracı — automation (C2).
3. OSS PR — başkasının koduna katkı (C3).

Mülakatçı OSS PR’a ayrı gözle bakar. Çünkü:

• Takım çalışması — sizin kodunuzu tanımayan birinin review’ından geçmiş.
• Topluluk standartları — lint, test, doc üçlüsünü öğrenmiş.
• Initiative — issue’yu kendi bulmuş, çözmüş.
• Profil timeline’ında görünür — mülakatçı GitHub’a girip commit history’sine bakar.

Adım 1: Proje Seçimi (küçük, aktif, davetkar)

İlk PR için küçük + aktif + “good first issue” etiketli proje. Büyük framework’e (Airflow, Spark) PR açmak ilk seferde eziyet olur.

Proje	Stack	Neden iyi?
dbt-utils	SQL + Python	”good first issue” çok, aktif maintainer, doc mükemmel
dlt-hub/verified-sources	Python	50+ kaynak, helper PR’ları izole
bruin-data/bruin	Go + SQL	Yeni ama davetkar, hızlı review
kestra-io/kestra	Java + YAML	Plugin eklemek izole, test altyapısı hazır
duckdb/duckdb	C++	Çok hızlı review, “good first issue” net

Seçim kriterleri:

1. Son 30 günde en az 5 PR merge edilmiş olsun.
2. good first issue veya help wanted etiketli issue’lar olsun.
3. CONTRIBUTING.md dosyası var mı kontrol et.
4. CI yeşil mi? (Son commit’te Actions ✓)
5. Issue’yu anlayıp 1 saat içinde çözüm planı çıkarabiliyor musun?

Adım 2: Issue’yu Claim Et

Issue’yu bulduğunda, yorum yaz:

Hi! I'd like to work on this issue. I'm new to contributing to
this project but I've been working through the DataTalksClub
DE Zoomcamp and I think I can tackle this in a focused PR.

My plan:
1. Add a unit test that reproduces the current behavior.
2. Implement the fix.
3. Update the docstring / README example if needed.
4. Run the full test suite locally.

Could you confirm this is a good approach before I start?
Thanks!

Neden bu uzunlukta?

• Sahiplenme gösterir (claim ediyorum).
• Plan paylaşır (maintainer güvenir).
• Soru ile bitirir (geri bildirim alır).
• Sabırlı bir ton (acele etmez).

Maintainer 1-3 gün cevap verebilir. Cevap gelene kadar bekleyin, paralel başka bir issue’ya bakın.

Adım 3: Fork, Branch, Code, Test

# 1) GitHub'da "Fork" butonu
git clone https://github.com/`<sizin>`/`<repo>`.git
cd `<repo>`

# 2) Upstream remote ekle
git remote add upstream https://github.com/`<org>`/`<repo>`.git
git fetch upstream

# 3) Feature branch
git checkout -b fix/issue-1234-null-check

# 4) Çalıştığını doğrula
make test  # veya pytest / npm test

# 5) Issue'yu reproduce eden test ekle (önce failing)
# ... test ekle, çalıştır, fail et ...

# 6) Fix uygula
# ... kod değişikliği ...

# 7) Test tekrar PASS
make test

# 8) Lint
pre-commit run --all-files

# 9) Commit (Conventional Commits önerilir)
git add .
git commit -m "fix(utils): add null check to pivot macro (#1234)"
git push origin fix/issue-1234-null-check

Surgical change kuralı: Sadece issue’da yazılı sorunu çözün. Yanlışlıkla fark ettiğiniz başka bug’ları ayrı PR yapın. “Drive-by refactor” PR’lar reddedilir.

Adım 4: PR Aç

Başlık: Fix #1234: Add null check to pivot macro (issue numarası referansı).

Açıklama:

## Summary
- Adds a `not_null` check to the `pivot()` macro.
- Returns the original input unchanged if all values are null
  (previously raised a confusing error).

## Why
Closes #1234 — without this, downstream models crash on
empty columns, which is a real issue in our dbt project.

## Changes
- `macros/utils/pivot.sql`: 3 lines added (null check)
- `tests/macros/test_pivot.py`: 2 new test cases
- `README.md`: 1 example updated

## Test plan
- [x] `pytest tests/macros/test_pivot.py` passes locally
- [x] `dbt run --select pivot_test` passes
- [ ] CI green (will check after push)

## Out of scope
- Refactor of `pivot()` (separate issue, see #1240)
- Documentation rewrite (separate PR)

Adım 5: Review Döngüsü

Maintainer ortalama 1-5 gün içinde review yapar. Olabilecek yorumlar:

Yorum	Cevabınız
”Could you add a test for X?"	"Good catch, added in latest commit."
"Let’s rename this variable"	"Done, renamed in commit abc123."
"I think we should use Y approach"	"You’re right, refactored. Let me know if you prefer it now."
"This is out of scope, please revert"	"Reverted. Should I open a separate issue for it?"
"LGTM, merging!”	Teşekkür yazın, sessizce bekleyin.

Asla tartışmayın. Maintainer gönüllü, siz misafirsiniz. Uzlaşmazsanız kendi fork’unuzda tutarsınız, “upstream’e katkı denemesi” portfolyo için yeterli.

Adım 6: Merge + Görünürlük

PR merge olduktan sonra:

1. GitHub profil timeline’da görünür.
2. LinkedIn postu: “İlk açık kaynak PR’ım merge oldu — `<repo>`’ya `<özelliği>` ekledim. [link]”
3. Blog yazısı (opsiyonel): süreci, öğrendiklerinizi, review yorumlarını anonimleştirilmiş şekilde anlatın.
4. Capstone C1 README’sine “Related projects” bölümüne ekleyin.

Tipik Hatalar ve Çözümleri

Hata	Belirtisi	Çözüm
PR çok büyük	Diff > 400 satır	Issue’yu parçalara böl, sadece bir parçayı PR yap
Test eksik	CI fail	Issue’da yazmasa bile en az 1 happy + 1 edge case
Lint / format fail	pre-commit red	Repo standartlarını takip et (black, ruff, sqlfmt)
Commit mesajı kötü	”fixed stuff”	Conventional Commits + issue ref
Review’a cevap yok	Maintainer “ping” istiyor	24 saat içinde cevap, “yarın dönüyorum” yaz
Scope creep	5 farklı değişiklik	Sadece sorunu çöz

Ne Öğrendik?

• Fork → branch → PR açık kaynak katkı döngüsü.
• Issue claim ve PR description profesyonelliği.
• Surgical change prensibi: sadece sorunu çöz, başka şeye dokunma.
• Review iletişimi: saygılı, kısa, çözüm odaklı.
• Profil timeline = sürekli portfolyo.

Sıradaki

Tebrikler! Kursun 3 capstone’unu da tamamladınız. Artık:

• End-to-end pipeline kurabilirsiniz (C1).
• Veri kalitesi ajanı yazabilirsiniz (C2).
• Açık kaynağa katkı döngüsünü bilirsiniz (C3).

Bir sonraki adım:

• Capstone C1’i LinkedIn Featured’a ekleyin, Loom demo çekin.
• dq-agent repo’sunu blog yazısı ile anlatın (mimari kararlar + öğrendikleriniz).
• Bir sonraki OSS PR’ınızı hedefleyin (C3’teki projeden bir tane daha).
• DataTalksClub canlı Ocak 2027 cohort’una katılın (ileri konular: ML feature store, vector DB, observability).

İyi yolculuklar.