Open Source Contribution | Ücretsiz Git & GitHub: Sıfırdan Pratiğe Kursu

Giriş — Mahalle İmecesi

Bir mahalle düşünün. Parklar, bahçeler, oyun alanları — hepsi ortak kullanım alanları. Bir gün birileri parkın bankını tamir ediyor, ertesi gün başka biri çiçek dikiyor, bir başkası çöpleri topluyor. Kimse bunu yapmak "zorunda" değil ama herkes katkıda bulununca park güzelleşiyor ve herkes faydalanıyor.

Açık kaynak (open source) yazılım dünyasının mahalle imecesidir. Linux, React, VS Code, Python, Node.js — günlük kullandığınız araçların çoğu açık kaynaklıdır. Binlerce geliştirici gönüllü olarak katkıda bulunur: bug düzeltir, yeni özellik ekler, dökümantasyon yazar, test ekler.

Bu derste, açık kaynak dünyasına nasıl adım atacağınızı, ilk katkınızı nasıl yapacağınızı ve topluluğun yazılı olmayan kurallarını öğreneceğiz.

Neden Open Source'a Katkı Yapmalısınız?

Kariyer Açısından

Açık kaynak katkısının kariyer etkileri:
──────────────────────────────────────────

📈 Deneyim      → Gerçek projelerde gerçek kod yazma deneyimi
👀 Görünürlük   → Recruiter'lar GitHub profilinize bakar
🤝 Network      → Dünyanın en iyi geliştiricileriyle çalışma
📚 Öğrenme      → Profesyonel kalitede kod okuma ve yazma
💼 CV/Portföy   → "React'a katkıda bulundum" etkili bir satırdır
🌍 Etki         → Milyonlarca kullanıcıyı etkileyen kod yazma

Kişisel Gelişim Açısından

Kod kalitesi: Katkınız binlerce kişi tarafından review edilir
İletişim: Uluslararası ekiplerle İngilizce iletişim
Yazılım mühendisliği: CI/CD, test, dökümantasyon best practices
Problem çözme: Farklı perspektiflerden sorunlara yaklaşma

İlk Katkıdan Önce: Hazırlık

1. Proje Seçimi

İlk katkınız için React veya Linux kernel'a PR açmanız beklenmez. Kendi seviyenize uygun projeler seçin:

Başlangıç seviyesi proje kriterleri:
✅ "good first issue" veya "help wanted" label'ları var
✅ CONTRIBUTING.md dosyası var (katkı rehberi)
✅ Aktif bakım yapılıyor (son commit < 3 ay)
✅ Issue'lara yanıt veriliyor (friendly community)
✅ Kullandığınız bir araç/kütüphane (motivasyon)
✅ Dili bildiğiniz bir proje

2. Proje Bulma Kaynakları

🔍 GitHub Topics
   github.com/topics/good-first-issue

🏷️ GitHub Label Arama
   github.com/search?q=label:"good+first+issue"+language:javascript

🌐 Özel Siteler
   goodfirstissue.dev
   firsttimersonly.com
   up-for-grabs.net
   codetriage.com

📅 Etkinlikler
   Hacktoberfest (Ekim ayı — her yıl)
   Google Summer of Code (GSoC)
   MLH Fellowship

3. Projeyi Tanıma

Bir projeye katkı yapmadan önce onu tanımanız gerekir:

# 1. README.md okuyun — proje ne yapıyor?
# 2. CONTRIBUTING.md okuyun — katkı kuralları ne?
# 3. CODE_OF_CONDUCT.md okuyun — davranış kuralları
# 4. Issue'ları inceleyin — hangi sorunlar var?
# 5. PR'ları inceleyin — nasıl katkılar kabul ediliyor?
# 6. Projeyi local'de çalıştırın — setup yapın

Fork Workflow — Adım Adım

Açık kaynak projelere katkıda bulunmak için Fork Workflow kullanılır:

Fork Workflow Akışı:

  Original Repo (upstream)
  github.com/facebook/react
       │
       │ Fork (GitHub'da "Fork" butonu)
       ▼
  Sizin Fork'unuz
  github.com/yourusername/react
       │
       │ git clone (local'e)
       ▼
  Local Repository
       │
       │ Branch oluştur, değişiklik yap, commit
       │
       │ git push (fork'unuza)
       ▼
  Fork'unuza push
       │
       │ Pull Request (fork → upstream)
       ▼
  PR Review → Merge

Adım 1: Fork ve Clone

# 1. GitHub'da "Fork" butonuna tıklayın
# → github.com/yourusername/awesome-project oluşur

# 2. Fork'unuzu clone edin
git clone https://github.com/yourusername/awesome-project.git
cd awesome-project

# 3. Upstream remote'u ekleyin
git remote add upstream https://github.com/original-owner/awesome-project.git

# 4. Remote'ları kontrol edin
git remote -v
# origin    https://github.com/yourusername/awesome-project.git (fetch)
# origin    https://github.com/yourusername/awesome-project.git (push)
# upstream  https://github.com/original-owner/awesome-project.git (fetch)
# upstream  https://github.com/original-owner/awesome-project.git (push)

Adım 2: Upstream ile Sync

Fork'unuzu her zaman upstream ile güncel tutmalısınız:

# Upstream'den çek
git fetch upstream

# Main branch'i güncelle
git checkout main
git merge upstream/main

# Fork'unuzun remote'una push edin
git push origin main

💡 İpucu: GitHub, fork sayfasında "Sync fork" butonu sunar. Tek tıkla upstream ile sync olabilirsiniz. Ama CLI'yı bilmek daha güvenilirdir.

Adım 3: Feature Branch Oluşturma

# Her zaman yeni branch oluşturun (asla main'de çalışmayın)
git checkout -b fix/typo-in-readme

# veya issue numarası ile
git checkout -b fix/42-login-bug

Adım 4: Değişiklik ve Commit

# Değişikliğinizi yapın
# ... kod yazın, test edin ...

# Projenin commit convention'ına uyun!
git add .
git commit -m "fix: correct typo in installation guide

Fixed 'intall' → 'install' in README.md setup section.

Fixes #42"

Adım 5: Push ve PR

# Fork'unuza push edin
git push origin fix/typo-in-readme

# GitHub'da PR açın (veya CLI ile)
gh pr create \
  --repo original-owner/awesome-project \
  --title "fix: correct typo in installation guide" \
  --body "Fixes #42

  Found a typo in the README installation section.

  ## Changes
  - Fixed 'intall' → 'install'

  ## Testing
  - Verified the documentation renders correctly"

Adım 6: Review Süreci

PR açtıktan sonra:

1. CI çalışır → testlerin geçtiğinden emin olun
2. Maintainer review eder
   ├── Approve → Merge 🎉
   ├── Request changes → Düzeltme yapın
   │   git add .
   │   git commit -m "fix: address review feedback"
   │   git push origin fix/typo-in-readme
   └── Comment → Tartışmaya katılın
3. Merge edildikten sonra
   git checkout main
   git branch -d fix/typo-in-readme
   git fetch upstream && git merge upstream/main

CONTRIBUTING.md — Katkı Rehberi

İyi bir proje, katkıcılar için net bir rehber sunar:

<!-- Örnek CONTRIBUTING.md -->

# Contributing to Awesome Project

## 🚀 Getting Started

1. Fork the repository
2. Clone your fork: `git clone https://github.com/you/awesome-project`
3. Install dependencies: `npm install`
4. Create a branch: `git checkout -b fix/your-fix`

## 📋 Development Setup

```bash
npm install          # Install dependencies
npm run dev          # Start development server
npm test             # Run tests
npm run lint         # Check code style

💡 How to Contribute

Bug Reports

Use the bug report template
Include steps to reproduce
Include expected vs actual behavior

Feature Requests

Use the feature request template
Explain the use case

Pull Requests

One PR per feature/fix
Follow our commit convention (Conventional Commits)
Add tests for new features
Update documentation if needed
All CI checks must pass

🎨 Code Style

We use ESLint + Prettier
Run npm run lint before committing
Follow existing code patterns

📝 Commit Convention

We follow Conventional Commits:

feat: new feature
fix: bug fix
docs: documentation
test: tests
chore: maintenance


## Katkı Türleri — Sadece Kod Değil

Açık kaynak katkısı sadece kod yazmak değildir:

Katkı Türü │ Örnek │ Zorluk ────────────────────┼────────────────────────────────┼──────── 📝 Dökümantasyon │ README düzeltme, tutorial yazma │ Kolay 🐛 Bug report │ Detaylı hata raporu │ Kolay 🌐 Çeviri │ Dökümantasyonu Türkçe'ye çevirme│ Kolay 🧪 Test ekleme │ Eksik test coverage'ı tamamlama │ Orta 🐛 Bug fix │ Bilinen bir hatayı düzeltme │ Orta 📦 Dependency │ Bağımlılıkları güncelleme │ Orta ✨ Feature │ Yeni özellik ekleme │ Zor ♻️ Refactoring │ Kod kalitesini iyileştirme │ Zor 🏗️ Architecture │ Mimari değişiklik │ Çok Zor


### İlk Katkı İçin Öneriler

En kolay başlangıç noktaları:

📝 Typo düzeltme (README, docs)
📝 Dökümantasyon iyileştirme (eksik bölüm ekleme)
🌐 Çeviri (i18n dosyaları)
🧪 Test ekleme (coverage artırma)
🐛 "good first issue" label'lı basit bug fix


## Community Etiquette — Topluluk Görgü Kuralları

### İletişim Kuralları

```markdown
## ✅ Yapın
- Nazik ve saygılı olun
- İngilizce yazın (uluslararası projeler)
- Issue açmadan önce mevcut issue'ları arayın (duplicate'den kaçının)
- PR'da ne yaptığınızı ve neden yaptığınızı açıklayın
- Geri bildirime açık olun
- Sabırlı olun (maintainer'lar gönüllü, zamanları sınırlı)
- Teşekkür edin, takdir edin

## ❌ Yapmayın
- "Bu ne zaman merge edilecek?" diye ısrar etmeyin
- Kendi PR'ınızı "acil" olarak etiketlemeyin
- Maintainer'ların kararlarını tartışmaya açmayın (özellikle ilk katkıda)
- Bir kerede çok büyük değişiklik göndermeyin
- Review yapılmadan merge beklemeyin
- Kişisel eleştiri yapmayın

Issue Açma Sanatı

<!-- İyi bir bug report -->

## Bug Report

### Description
The login form shows a blank page after clicking submit.

### Steps to Reproduce
1. Go to /login
2. Enter valid credentials
3. Click "Login"
4. Page goes blank (expected: redirect to dashboard)

### Environment
- OS: macOS 14.2
- Browser: Chrome 120
- Node.js: 20.10.0
- Package version: 2.3.1

### Screenshots
[ekran görüntüsü ekleyin]

### Additional Context
This started after upgrading to v2.3.1. v2.3.0 works fine.

PR Açma Sanatı

<!-- İyi bir PR description -->

## Description
Fix blank page on login form submission (#42)

The issue was caused by an unhandled promise rejection
in the auth service when the API returns a 200 status
with an empty body.

## Changes
- Added null check for API response body in `auth.service.ts`
- Added error boundary for the login page
- Added unit test for empty response scenario

## Testing
- [x] Added unit test: `auth.service.test.ts`
- [x] Manual testing: login works with valid/invalid credentials
- [x] Tested on Chrome, Firefox, Safari

## Related Issues
Fixes #42

⚠️ Dikkat: PR açtıktan sonra maintainer review etmeyebilir — sabrın olsun. 1-2 hafta bekleyin, sonra nazikçe bir yorum bırakın: "Hi, just checking in — is there anything I can improve in this PR?" İlk katkınızda reddedilmek normal — öğrenme fırsatı olarak görün.

Maintainer ile İletişim Stratejisi

İlk katkınızda maintainer ile doğru iletişim kurmak kritiktir:

İlk Temas — Issue Yorumu

# Issue'da katkı niyetinizi belirtin:

"Hi! I'd like to work on this issue. I've read the CONTRIBUTING.md
and I have a plan:

1. Add input validation for description length
2. Add unit tests for edge cases
3. Update the docs if needed

Could you assign this to me? Thanks!"

PR Açarken

# PR description şablonu:

## What does this PR do?
Fixes the crash when description exceeds 256 characters (#42)

## How was this tested?
- Added unit tests for long descriptions
- Manual testing with various input lengths
- Tested on Node.js 18, 20, and 22

## Checklist
- [x] Tests pass locally
- [x] Lint passes
- [x] Documentation updated
- [x] Follows coding conventions

## Screenshots (if applicable)
N/A (no UI changes)

Review Feedback'e Yanıt Verme

# Maintainer değişiklik istedi
# 1. Değişiklikleri yap
$ git add .
$ git commit -m "fix: address review feedback - use MAX_LENGTH constant"

# 2. Push et (aynı branch'e — PR otomatik güncellenir)
$ git push origin fix/long-description-crash

# 3. PR'da yorum bırak:
# "Thanks for the review! I've:
# - Extracted the magic number into a MAX_LENGTH constant
# - Added a test for the boundary condition
# Please take another look 🙏"

💡 İpucu: Review feedback'ine asla savunmacı yaklaşmayın. Maintainer'lar projeyi en iyi bilenlerdir. "Ama ben böyle düşündüm" yerine "İyi fikir, düzelttim" yaklaşımı hem işinizi hem ilişkinizi iyileştirir.

Açık Kaynak Hukuki Bilgiler

CLA (Contributor License Agreement)

Bazı büyük projeler (React, Angular, Kubernetes) katkıcılardan CLA imzalatır:

CLA ne yapar?
→ Katkınızın telif haklarını projeye devreder (veya lisanslar)
→ Projenin lisansını değiştirmesine izin verir
→ Patent haklarını düzenler

CLA gerektiren projeler:
• Meta (React, Jest)
• Google (Angular, Go)  
• Microsoft (VS Code, TypeScript)
• Apache Foundation projeleri

CLA nasıl imzalanır?
→ İlk PR'da CLA bot otomatik yorum bırakır
→ Linke tıklayıp dijital imza atarsınız
→ Tek seferlik — sonraki PR'larda gerekmez

Gerçek Dünya Senaryosu: İlk Open Source PR

Diyelim ki awesome-todo-app adlı bir npm paketini kullanıyorsunuz ve bir bug buldunuz:

# 1. Bug'ı tespit ettiniz
# Todo item'ın description'ı 256 karakterden uzunsa crash oluyor

# 2. Issue kontrolü
# GitHub'da mevcut issue var mı? → Yok

# 3. Issue açın
# Title: "Crash when todo description exceeds 256 characters"
# Body: Steps to reproduce, environment info, expected behavior

# 4. Maintainer yanıt verdi: "Good catch! Would you like to submit a PR?"

# 5. Fork ve clone
gh repo fork awesome-org/awesome-todo-app --clone
cd awesome-todo-app
git remote add upstream https://github.com/awesome-org/awesome-todo-app.git

# 6. Setup
npm install
npm test  # Mevcut testlerin geçtiğinden emin ol

# 7. Branch
git checkout -b fix/long-description-crash

# 8. Fix

// src/todo.js — ÖNCE (bug'lı)
function createTodo(title, description) {
  return {
    id: generateId(),
    title,
    description,  // Uzun description'da buffer overflow
    createdAt: new Date()
  };
}

// src/todo.js — SONRA (düzeltilmiş)
function createTodo(title, description) {
  if (typeof description !== 'string') {
    throw new TypeError('Description must be a string');
  }

  return {
    id: generateId(),
    title,
    description: description.slice(0, 10000), // Makul bir limit
    createdAt: new Date()
  };
}

// test/todo.test.js — Test ekleme
describe('createTodo', () => {
  it('should handle long descriptions', () => {
    const longDesc = 'a'.repeat(50000);
    const todo = createTodo('Test', longDesc);
    expect(todo.description.length).toBeLessThanOrEqual(10000);
  });

  it('should throw on non-string description', () => {
    expect(() => createTodo('Test', 42)).toThrow(TypeError);
  });
});

# 9. Test, lint, commit
npm test       # Tüm testler geçiyor ✅
npm run lint   # Linting temiz ✅

git add .
git commit -m "fix: handle long descriptions to prevent crash

Added input validation and length limit for todo descriptions.
Previously, descriptions longer than 256 characters caused a
buffer overflow crash.

Added tests for edge cases.

Fixes #123"

# 10. Push ve PR
git push origin fix/long-description-crash
gh pr create \
  --repo awesome-org/awesome-todo-app \
  --title "fix: handle long descriptions to prevent crash" \
  --body "Fixes #123 ..."

# 11. Review bekle, feedback'e göre düzelt
# 12. Merge! İlk open source katkınız! 🎉🎉🎉

Open Source Proje Başlatma

Kendi açık kaynak projenizi başlatmak da bir katkıdır:

# Minimum dosya yapısı
my-open-source-project/
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── bug_report.md
│   │   └── feature_request.md
│   ├── pull_request_template.md
│   └── workflows/
│       └── ci.yml
├── src/
├── tests/
├── .gitignore
├── .editorconfig
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE               # MIT, Apache 2.0, GPL vb.
├── README.md
└── package.json

Lisans Seçimi

Lisans              │ İzinler                │ Ne zaman?
────────────────────┼────────────────────────┼──────────────
MIT                 │ Her şey serbest,       │ Maksimum özgürlük,
                    │ sadece attribution     │ en popüler
Apache 2.0          │ MIT + patent koruması  │ Kurumsal projeler
GPL v3              │ Türetilen iş de GPL    │ Copyleft istiyorsanız
                    │ olmalı                 │
BSD 2-Clause        │ MIT benzeri            │ Akademik projeler
ISC                 │ MIT benzeri, daha kısa │ npm varsayılanı
Unlicense           │ Public domain          │ Tam serbestlik

💡 İpucu: Emin değilseniz MIT lisansı seçin. En yaygın, en basit, en kısıtlamasız açık kaynak lisansıdır. choosealicense.com sitesinden karşılaştırma yapabilirsiniz.

Özet

Bu derste açık kaynak dünyasına nasıl katkıda bulunacağınızı öğrendik:

🍴 Fork workflow — fork → clone → branch → commit → push → PR
🔄 Upstream sync — fork'unuzu upstream ile güncel tutma
📋 CONTRIBUTING.md — projenin katkı kurallarını okuma
🏷️ Good first issue — başlangıç seviyesi görevler bulma
🤝 Community etiquette — nazik, sabırlı, yapıcı iletişim
🐛 Katkı türleri — sadece kod değil: docs, test, çeviri, bug report
📄 Lisans — MIT en yaygın ve en özgür seçim

Bir sonraki derste GitHub portföyünüzü nasıl güçlendireceğinizi öğreneceğiz: profil README, pinned repos ve contribution graph stratejileri.