Kaliteyi Koddan Önce Tanımlamak

Açık kaynak projenin sürdürülebilirliği yalnızca kod kalitesiyle ölçülmez. Yeni bir katkının güvenle incelenebilmesi, kullanıcıların projeyi kurabilmesi ve bakım yükünün öngörülebilmesi için süreçler baştan tanımlanmalıdır. Desteklenen işletim sistemi, çalışma zamanı sürümleri, kalite beklentileri ve katkı sınırları belgelenmelidir.

README içinde en az şu bilgiler bulunmalıdır:

• Projenin çözdüğü problem ve hedef kullanıcı grubu
• Kurulum, yapılandırma ve ilk çalıştırma adımları
• Desteklenen sürümler, bilinen kısıtlar ve uyumluluk notları
• Test, lint, format ve build komutları
• Issue, güvenlik bildirimi ve katkı gönderme kanalları
• Lisans ile üçüncü taraf bileşenlere ilişkin bilgiler

Kurulum talimatları temiz bir ortamda düzenli olarak denenmeli; örnek yapılandırma dosyaları gerçek sırlar içermemelidir. Belgelerdeki her komut, mümkünse CI içinde de çalıştırılarak README ile gerçek proje davranışı arasındaki fark azaltılmalıdır.

Lisans ve Hak Sahipliğini Netleştirmek

Lisans seçimi, depoya yalnızca bir LICENSE dosyası eklemekten ibaret değildir. Lisans; dağıtım modeli, ticari kullanım beklentisi, türev çalışmalar ve katkıların projeye nasıl dahil edileceğiyle uyumlu olmalıdır. Karar verilmeden önce projenin kütüphane mi, uygulama mı yoksa servis bileşeni mi olduğu değerlendirilmelidir.

Şu kontroller yapılmalıdır:

• Lisans dosyası depo kökünde bulunmalı; README ve paket metadatasındaki bilgilerle tutarlı olmalı
• Telif ve bildirim yükümlülükleri korunmalı
• Doğrudan ve geçişli bağımlılıkların lisansları incelenmeli
• Katkıcı lisans sözleşmesi veya katkı politikası gerekip gerekmediği belirlenmeli
• Belirsiz lisanslı kod, şartları doğrulanmadan üretim dağıtımına alınmamalı

Hukuki yorum gerektiren durumlarda teknik ekip tek başına kesin hüküm vermemelidir. Lisans envanterinin sürüm değişiklikleriyle birlikte güncellenmesi, yayın öncesi kontrol listesinin parçası olmalıdır.

Issue ve Pull Request Akışını Tasarlamak

Issue şablonları eksik ve tekrarlanan kayıtları azaltır. Hata bildiriminde beklenen ve gerçekleşen davranış, yeniden üretim adımları, minimal örnek, ortam bilgisi ve ilgili sürüm istenmelidir. Özellik önerilerinde ise çözülmek istenen problem, alternatifler, kapsam ve geriye dönük uyumluluk etkisi açıklanmalıdır.

Pull request'ler küçük ve tek amaca odaklı tutulmalıdır. Maintainer incelemesinde şu sorular sorulabilir:

• API, veri formatı veya varsayılan davranış değişiyor mu?
• Testler normal akışın yanında hata senaryolarını da kapsıyor mu?
• README, changelog veya migration belgesi güncellenmeli mi?
• Güvenlik, performans ve uyumluluk açısından yeni risk oluşuyor mu?
• CI sonuçları yerel ve uzak ortamda tekrarlanabilir mi?

Kod incelemesi kişiye değil değişikliğe odaklanmalı; önemli kararların gerekçesi PR içinde kayda geçirilmelidir. Kapanan issue'lar için kısa ve saygılı açıklamalar sağlamak, katkıcıların aynı sorunu tekrar açmasını ve bakım yükünü azaltır. Güvenlik açıkları kamuya açık issue yerine proje tarafından belirlenmiş özel bildirim kanalıyla ele alınmalıdır.

Sürümleme ve Değişiklik Yönetimi

Sürüm numarası, changelog ve yayın notları aynı hikâyeyi anlatmalıdır. Semantik sürümleme kullanılıyorsa geriye dönük uyumsuz değişiklikler, yeni özellikler ve düzeltmeler açıkça ayrılmalıdır. Sürüm numarası tek başına yeterli değildir; yapılandırma, API ve veri şeması etkileri ayrıca belirtilmelidir.

Yayın öncesi kontrol listesi şöyle olabilir:

• Test, lint, statik analiz ve güvenlik kontrollerini incelemek
• Değişen API, yapılandırma ve varsayılanları listelemek
• Deprecation, migration ve rollback adımlarını doğrulamak
• Yayın paketini temiz bir ortamda kurup denemek
• Yayın notlarında bilinen riskleri ve yükseltme gereksinimlerini belirtmek

Kritik projelerde kademeli yayın veya kısa bir gözlem dönemi uygulanabilir. Geri alma adımı, sürüm yayınlandıktan sonra düşünülmemeli; yayın planının parçası olmalıdır.

Dependency Güvenliğini Operasyonel Hale Getirmek

Bağımlılık güvenliği tek seferlik taramayla tamamlanmaz. Manifest ve kilit dosyaları birlikte yönetilmeli, doğrudan ve geçişli bağımlılıklar düzenli olarak envantere alınmalıdır. Otomatik güncelleme araçlarının açtığı PR'lar; test, lisans, performans ve değişiklik etkisi incelenmeden birleştirilmemelidir.

Uygulanabilir bir rutin:

• Kullanılmayan paketleri kaldırmak ve bağımlılık sahipliğini belirlemek
• Güvenlik uyarılarını etkilenen sürüm, erişilebilirlik ve önem derecesine göre sınıflandırmak
• Üretim imajlarını sabit, doğrulanabilir sürümlerle oluşturmak
• Kilit dosyalarını rastgele elle değiştirmemek; güncellemeyi araç ve inceleme süreciyle yapmak
• Gerekirse bağımlılık envanteri veya SBOM üretmek
• Gizli anahtarları depoya koymamak; sızıntı halinde iptal ve döndürme planı bulundurmak

Kritik bir açık için yama, sürüm yükseltme, geçici kısıtlama veya etkilenen özelliği devre dışı bırakma seçenekleri önceden tanımlanmalıdır. Kararın kim tarafından, hangi sürede ve hangi iletişim kanalıyla alınacağı belgelenirse kriz anındaki belirsizlik azalır.

Sürdürülebilirlik İçin Son Kontrol

İyi bir depo, bugünkü katkıyı değil altı ay sonraki bakım yükünü de hesaba katar. README, lisans, issue şablonları, CI, sürüm notları ve dependency politikası birlikte çalışmalıdır.

Düzenli aralıklarla şu soruyu sormak yararlıdır: Yeni bir katkıcı projeyi kurup güvenli bir değişikliği, özel yardım almadan gönderebilir mi? Yanıt hayırsa sorun çoğu zaman katkıcıda değil, belgelenmemiş veya uygulanmayan süreçtedir.