Açık Kaynak Proje Web Sitesini Topluluk Katkısıyla Oluşturun

Web sitesinin amacını ve hedef kitlesini netleştirin

Bir tema seçmeden veya ana sayfa taslağı çizmeden önce sitenin ne için olduğunu belirleyin. Açık kaynak siteleri genellikle aynı anda her şeye hizmet etmeye çalışır—doküman portalı, pazarlama sayfası, topluluk merkezi, blog, bağış akışı—ve sonunda hiçbirini iyi yapamazlar.

Birincil hedefleri tanımlayın

Sitenin yerine getirmesi gereken en önemli 1–3 işi yazın. Yaygın örnekler:

• Dokümantasyon: kullanıcıların hızla başarılı olmasına yardım edin (kurulum, öğreticiler, API referansı).
• İndirmeler: sürümleri, paketleri veya konteynerleri nereden alacakları açık olsun.
• Topluluk: soru sorma, sohbete katılma, issue bulma veya toplantılara katılma yollarını gösterin.
• Güncellemeler: sürüm notları, duyurular ve yol haritası değişikliklerini yayınlayın.

Sitenin amacını bir cümlede açıklayamıyorsanız, ziyaretçiler de yapamaz.

Hedef kitleleri belirleyin (ve onların neye ihtiyacı var)

Ana hedef kitlelerinizi ve her grubun yapmasını istediğiniz “ilk tıklamayı” listeleyin:

• Kullanıcılar hızlı başlangıç, sorun giderme ve sürüme özgü doküman ister.
• Katkıda bulunanlar net katkı adımları ve “good first issues” ister.
• Bakıcılar düşük sürtünmeli yayın süreci ve öngörülebilir incelemeler ister.
• Sponsorlar etki kanıtı ve projeyi desteklemenin kolay bir yolunu ister.

Yararlı bir egzersiz: her kitle için gelen ilk 3 soruyu yazın (ör. “Nasıl kurulur?”, “Bu aktif mi?”, “Hata nerede bildirilir?”).

Gerçekçi ölçülebilir başarı metrikleri seçin

Hedeflerinize bağlı, izlemesi gerçekçi basit metrikler seçin:

• Doküman hedefi → önemli doküman sayfalarına trafik, arama sorguları, ilk başarıya ulaşma süresi.
• Topluluk hedefi → ilk kez katkıda bulunan sayısı, triage edilmiş issue’lar, birleştirilen PR’ler.
• Güncellemeler hedefi → bülten kayıtları, RSS aboneleri, sürüm yazısı görüntülenmeleri.

Kapsam dışı hedefleri (non-goals) belirtin

Sitenin yapmayacağı şeyleri açıkça listeleyin (şimdilik): özel web uygulamaları, karmaşık hesap sistemleri, ağır entegrasyonlar veya özel CMS özellikleri. Bu, bakıcıların zamanını korur ve projeyi gönderilebilir tutar.

Topluluğun neyi düzenleyebileceğine vs. bakıcıların neye özel olduğuna karar verin

İçeriği iki kovana ayırın:

• Topluluk tarafından düzenlenebilir: dokümanlar, SSS, öğreticiler, çeviriler, örnekler, yazım düzeltmeleri.
• Sadece bakıcılar: güvenlik sayfaları, yasal/politika metinleri, yönetişim kararları, resmi açıklamalar.

Bu tek karar ileride araç seçimlerinizi, inceleme iş akışınızı ve katkı deneyimini şekillendirir.

Site yapısını ve içerik modelini planlayın

Topluluk sitesi hızla dağılabilir; “siteye neyin ait olduğu” ile repodaki içeriğin nerede tutulacağına karar vermezseniz. Araçlar ve temalar öncesinde basit bir yapı ve net bir içerik modeli konusunda anlaşın—böylece katkıcılar nerede ekleme yapacaklarını bilir ve bakıcılar nasıl inceleyeceklerini bilirler.

İnsanların düşündüğü şekilde bir sitemap ile başlayın

Birincil navigasyonu kasıtlı olarak sade tutun. Açık kaynak proje sitesi için iyi bir varsayılan sitemap:

• Home: proje nedir, neden var, hızlı bağlantılar
• Docs: hızlı başlangıç, rehberler, API/referans, SSS
• Blog/News: sürümler, duyurular, topluluk öne çıkanlar
• Community: sohbet/forum linkleri, etkinlikler, davranış kuralları
• Contribute: “nasıl yardım edilir”, başlangıç sorunları, katkı adımları
• Governance: karar alma, bakıcılar, politikalar

Bir sayfa bunlardan birine uymuyorsa, bu bilginin repoda daha uygun olduğunu veya yeni bir içerik türüne ihtiyaç olduğunu gösterir.

Sitede mi yoksa repo README’sinde mi yaşatılacağına karar verin

README’yi geliştiriciye yönelik temel bilgiler için kullanın: derleme talimatları, yerel geliştirme kurulumu, testler ve kısa proje durumu. Siteyi ise şunlar için kullanın:

• Yeni kullanıcılar ve katkıcılar için onboarding içerikleri
• Uzun rehberler ve öğreticiler
• Kamuya açık politikalar (Code of Conduct, yönetişim)
• Sürüm notları ve duyurular

Bu ayrım, içeriğin aynı anda iki yerde sürüklenip uyumsuzlaşmasını önler.

Sahiplik, ton ve versiyonlamayı baştan belirleyin

Alan bazında (içerik sahipleri) atama yapın (dokümanlar, blog/haber, çeviriler). Sahiplik tek bir engelleyici olmak zorunda değil; küçük bir grup, net inceleme sorumluluğu ile olabilir.

Küresel bir topluluğa dost bir ton ve stil rehberi yazın: yalın dil, tutarlı terimler ve ana dili İngilizce olmayan yazarlar için rehberlik.

Projeniz sürümler yayıyorsa, erken dönemde versiyonlu dokümanlar planlayın (ör. “latest” ve desteklenen sürümler). Birden fazla sürüm çıktıktan sonra yapıyı sonradan değiştirmek zordur.

Katkıyı destekleyen bir teknoloji yığını seçin

Web sitesi yığını, birinin bir yazım hatasını düzeltmesini, yeni bir sayfa eklemesini veya dokümanı geliştirmesini kolaylaştırmalı—bir derleme mühendisine dönüşmeden. Çoğu açık kaynak proje için bu şunu gerektirir: Markdown-öncelikli içerik, hızlı yerel kurulum ve sorunsuz bir pull request iş akışı ile önizlemeler.

Düzeni ve navigasyonu hızla iterasyona sokmayı planlıyorsanız, kalıcı bir yığına karar vermeden önce site deneyimini prototiplemeyi düşünün. Platformlar gibi Koder.ai sohbet yoluyla docs/pazarlama sitesi taslağı oluşturmanıza, gerektiğinde backend ile çalışan bir React tabanlı UI üretmenize ve sonra kaynak kodu repoya aktarılacak şekilde dışa aktarmanıza yardımcı olabilir—bu, bilgi mimarisi ve katkı akışlarını haftalar süren kurulum olmadan keşfetmek için faydalıdır.

Topluluk düzenlemeleri için uygun statik site üreticileri

Aşağıda katkı-odaklı dokümanlar ve proje siteleri için yaygın seçeneklerin durumu:

• Docusaurus: versiyonlama, sidebar navigasyonu ve yerleşik arama seçenekleriyle doküman siteleri için harika. Yerel kurulum basit (Node) ve PR tabanlı dokümantasyon için optimize edilmiştir.
• MkDocs (özellikle Material ile): katkıcılar için çok ulaşılabilir—Markdown yazın, mkdocs.yml düzenleyin ve tek bir komut çalıştırın.
• Hugo: son derece hızlı derlemeler ve esnek içerik türleri. Tema/şablon karmaşıklığı biraz daha fazla olabilir ancak hem doküman hem de daha zengin pazarlama sayfası istediğinizde mükemmeldir.
• Jekyll: GitHub Pages ile sorunsuz çalışır, ancak yeni araçlara göre daha az ergonomik gelebilir. Basit siteler için hâlâ uygundur.
• Astro: modern, içerik ağırlıklı siteler ve bileşen tabanlı sayfalar için mükemmel. Dokümanların ötesinde özel UI bekliyorsanız tercih edin.

Hosting ve önizlemeler: “PR → önizleme → merge” öncelikli olsun

Katkıcıların değişikliklerini yayınlamadan önce canlı görebilmeleri için önizleme derlemelerini destekleyen bir hosting seçin:

• GitHub Pages / GitLab Pages: basit ve tanıdık; önizlemeler ek CI yapılandırması gerektirebilir.
• Netlify / Cloudflare Pages: PR önizleme desteği kutudan çıkar ve kolay geri alma sağlar.

Varsa varsayılan yolu “PR aç, önizleme al, inceleme iste, merge et” olacak şekilde kurun. Bu, bakıcıların geribildirimi azaltır ve katkıcı güvenini artırır.

Kararı belgeleyin ki yeniler tahmin yürümesin

Kısa bir docs/website-stack.md (veya README.md içinde bir bölüm) ekleyin: ne seçtiğinizi ve nedenini; siteyi yerelde nasıl çalıştıracağınızı, önizlemelerin nerede göründüğünü ve hangi değişikliklerin website reposunda olması gerektiğini yazın.

İş birliği için repoyu hazırlayın

Dostane bir repo, “geçici düzenlemeler” ile sürekli katkı arasında fark yaratır. Gezinmesi kolay, inceleyiciler için öngörülebilir ve yerelde çalıştırması basit bir yapı hedefleyin.

Önerilen repo düzeni

Web ile ilgili dosyaları gruplayın ve açıkça adlandırın. Yaygın bir yaklaşım:

/
  /website        # pazarlama sayfaları, açılış, navigasyon
  /docs           # doküman kaynakları (referans, rehberler)
  /blog           # sürüm notları, duyurular, hikayeler
  /static         # görseller, simgeler, indirilebilir varlıklar
  /.github        # issue şablonları, workflow’lar, CODEOWNERS
  README.md       # repo genel bakışı

Eğer proje zaten uygulama kodu içeriyorsa, siteyi /website (veya /site) içine koyun ki katkıcılar nereden başlayacaklarını tahmin etmesin.

/website içinde odaklı bir README ekleyin

/website/README.md oluşturun ve “Değişikliğimi nasıl önizlerim?” sorusuna cevap verin. Kısa ve kopyala-yapıştır yapılabilir olsun.

Örnek quickstart (yığına göre uyarlayın):

# Website quickstart

## Requirements
- Node.js 20+

## Install
npm install

## Run locally
npm run dev

## Build
npm run build

## Lint (optional)
npm run lint

Ayrıca ana dosyaların (navigasyon, footer, yönlendirmeler) nerede olduğunu ve yeni bir sayfa eklemenin nasıl yapılacağını belirtin.

Kopyalanıp yapıştırılabilir içerik şablonları sağlayın

Şablonlar biçim tartışmalarını azaltır ve incelemeleri hızlandırır. Bir /templates klasörü ekleyin (veya /docs/CONTRIBUTING.md içinde şablonları belgeleyin).

/templates
  docs-page.md
  tutorial.md
  announcement.md

Basit bir doküman sayfası şablonu şöyle olabilir:

---
title: "Sayfa başlığı"
description: "Bir cümlelik özet"
---

## Ne öğreneceksiniz

## Adımlar

## Sorun giderme

İncelemeleri CODEOWNERS ile yönlendirin (uygunsa)

Belirli alanlarda bakıcılarınız varsa /.github/CODEOWNERS ekleyin ki doğru kişiler otomatik olarak ister yapılsın:

/docs/    @docs-team
/blog/    @community-team
/website/ @web-maintainers

Konfigürasyonu minimal ve iyi yorumlanmış tutun

Her araç için bir kanonik konfigürasyon dosyası tercih edin ve kısa neden açıklamaları ekleyin. Hedef, yeni bir katkıcının menü öğesi değiştirebilmesi veya yazım hatasını düzeltebilmesi için tüm build sisteminizi öğrenmesine gerek kalmamasıdır.

İnsanların takip edeceği katkı yönergeleri oluşturun

Bir web sitesi kod tabanından farklı katkı çeker: metin düzeltmeleri, yeni örnekler, ekran görüntüleri, çeviriler ve küçük UX düzelmeleri. Eğer CONTRIBUTING.md sadece geliştiriciler için yazıldıysa, birçok potansiyel yardımı kaybedersiniz.

CONTRIBUTING.md’yi “site-odaklı” yapın

CONTRIBUTING.md oluşturun veya ayırın; site değişikliklerine odaklansın: içerik nerede yaşar, sayfalar nasıl üretilir ve “tamam” ne demektir. Kısa bir “yaygın görevler” tablosu (yazım hatası düzeltme, yeni sayfa ekleme, navigasyon güncelleme, blog gönderisi yayınlama) ekleyin ki yeniler dakikalar içinde başlayabilsin.

Var olan daha derin rehberleriniz varsa, bunlara CONTRIBUTING.md üzerinden açıkça bağlayın (örneğin /docs altında bir yürütme sayfası).

Düzenleme önermek için issue vs PR nasıl kullanılır açıklayın

Ne zaman önce issue açılmalı, ne zaman doğrudan PR gönderilebileceğini açık belirtin:

• Önce issue açın yeni sayfalar, yapısal değişiklikler veya ton/konumlandırma gibi tartışma gerektiren her şey için.
• Doğrudan PR’ler hoş karşılanır yazım hataları, kırık linkler, küçük açıklamalar ve bariz güncellemeler için.

Ayrıca “iyi issue şablonu” örneği ekleyin: hangi sayfa URL’si, ne değişecek, okuyucuya nasıl yardımcı olur ve kaynaklar.

Güvenilir inceleme beklentileri belirleyin

Çoğu hayal kırıklığı sessizlikten gelir, geribildirimden değil. Şunları tanımlayın:

• Tipik yanıt süresi (ör. “3 iş günü içinde onaylanır”)
• Gerekli onaylar (ör. yeni sayfalar için bir bakıcı + bir doküman inceleyicisi)
• Stil kontrolleri (linter’lar, formatlama, link kontrolü, yazım denetimi) ve katkıcıların bunları yerelde çalıştırıp çalıştırmayacağı

Her PR için içerik kontrol listesi ekleyin

Hafif bir kontrol listesi sonradan gidip gelmeyi engeller:

• Linkler çalışıyor (iç sayfalar için göreli link tercih edin)
• Ekran görüntüleri güncel ve alt metinleri var
• Başlıklar taranabilir; ton mevcut dokümanlarla uyumlu
• Erişilebilirlik temelleri: renk kontrastı, klavye dostu desenler, açıklayıcı link metni
• Kullanıcıları etkileyen değişiklikse değişiklik günlüğü notu

İnceleme ve yayınlama iş akışını tasarlayın

Bir katkı açıldıktan sonra ne olacağı kesinse site sağlıklı kalır. Hedef, öngörülebilir, düşük sürtünmeli ve güvenle yayınlanabilecek bir iş akışıdır.

Geri-gönderimi azaltacak bir PR şablonu ile başlayın

Bir pull request şablonu ekleyin (ör. .github/pull_request_template.md) ve sadece inceleyicilerin ihtiyaç duyduğu soruları sorun:

• Ne değişti? (bir-iki cümle)
• Neden? (issue linki veya bağlam)
• Ekran görüntüleri (görsel değişiklikler için—önce/sonra)
• İçerik kontrol listesi (yazım, linkler, frontmatter)

Bu yapı incelemeleri hızlandırır ve katkıcılara “iyi” örneği öğretir.

Her PR’i önizlemelerle tıklanabilir kılın

Önizleme dağıtımlarını etkinleştirin ki inceleyiciler değişikliği gerçek site üzerinde görebilsin. Bu, navigasyon güncellemeleri, stil ve düzen hataları için özellikle faydalıdır.

Yaygın desen:

• PR açılır → CI siteyi derler
• Hosting sağlayıcı PR’e önizleme URL’si gönderir
• İnceleyiciler tıklar, doğrular ve değişiklik isterse istekte bulunur

Sıkıcı işleri otomatikleştirin

Her PR’de hafif kapılar çalıştırmak için CI kullanın:

• Link checker kırık linkleri yakalaması için
• Markdown lint formatı korumak için
• Formatlama (Prettier vb.) stil tartışmalarını önlemek için

Hızlıca başarısız olsun ve açık hata mesajları versin ki katkıcılar bakıcı müdahalesi olmadan düzeltebilsin.

Yayınlamayı basit tutun: main’e merge otomatik deploy etsin

Tek bir kural belgeleyin: PR onaylandıktan ve main’e merge edildikten sonra site otomatik yayımlanır. Elle adımlar veya gizli komutlar olmasın. Kesin davranışı /contributing içinde belirtin ki beklentiler net olsun.

Platformunuz snapshot/rollback destekliyorsa (bazı hostlar yapar, Koder.ai ile deploy ettiğinizde de benzer özellik varsa) “son iyi derleme”nin nerede bulunacağını ve nasıl geri alınacağını belgeleyin.

Geri alma adımlarını önceden yazın

Dağıtımlar bazen bozulur. Kısa bir geri alma oyun planı belgeleyin:

• Merge commit’i geri al (revert) veya son iyi tag’i geri yükle
• Deploy’un yeniden çalıştığını doğrula
• Ne olduğuna ve nasıl önleneceğine dair takip issue aç

İçerik için tutarlı bir tasarım sistemi oluşturun

Sayfalar aynı yerdeymiş gibi hissettirdiğinde topluluk sitesi davetkâr kalır. Hafif bir tasarım sistemi katkıcıların daha hızlı hareket etmesini sağlar, inceleme tartışmalarını azaltır ve büyüdükçe okuyucuları oryante eder.

Yeniden kullanılabilir sayfa düzenleri ve navigasyon kuralları ile başlayın

Küçük bir sayfa “tipi” seti tanımlayın ve bunlara sadık kalın: doküman sayfası, blog/haber yazısı, açılış sayfası ve referans sayfası. Her tip için her zaman görünmesi gerekenleri (başlık, özet, son güncelleme, içerik tablosu, footer linkleri) ve asla olmaması gerekenleri belirleyin.

Navigasyon kurallarıyla netliği koruyun:

• Üst seviye navigasyon kategorilerini sabit tutun; yeni sayfaları önce mevcut gruplar içinde ekleyin.
• Yan menülerde 3’ten fazla iç içe seviye olmaktan kaçının.
• Yeni sayfaların hiyerarşide nerede olduğunu belirtmesini zorunlu kılın (ör. sidebar_position veya weight).

Katkıcıların yeniden kullanabileceği içerik bileşenleri oluşturun

Katkıcıları “uygun görünmesini sağla” diye zorlamak yerine yapı taşları verin:

• Notlar, uyarılar ve ipuçları için çağrı kutuları
• Dil etiketli standart kod blokları, satır sarma kuralları ve kopyala düğmeleri
• API referans desenleri (endpoint tablosu, parametreler, cevaplar, örnekler)

Bu bileşenleri kısa bir “Content UI Kit” sayfasında belgeleyin (ör. /docs/style-guide) ve kopyala-yapıştır örnekleri verin.

Markalaşmayı hafif tutun

Asgariyi belirleyin: logo kullanımı (esnemeye veya yeniden renklendirmeye izin yok), 2–3 temel renk ile erişilebilir kontrast, bir veya iki font. Amaç “yeterince iyi”yi kolaylaştırmak, yaratıcılığı sıkı şekilde engellemek değil.

Ekran görüntüleri ve diyagramları güncel tutmayı kolaylaştırın

Kurallar üzerinde anlaşın: sabit genişlikler, tutarlı padding ve feature-name__settings-dialog.png gibi adlandırma. Diyagramlar için kaynak dosyalarını tercih edin (ör. Mermaid veya düzenlenebilir SVG) ki güncelleme bir tasarımcı gerektirmesin.

Bilgi hiyerarşisini koruyun

PR şablonuna basit bir kontrol listesi ekleyin: “Bunun zaten bir sayfası var mı?”, “Başlık içinde olduğu bölüme uyuyor mu?”, “Yeni bir üst seviye kategori oluşturacak mı?” Böylece içerik dağılmasını önlerken katkıyı da teşvik edersiniz.

Siteyi erişilebilir, hızlı ve keşfedilebilir kılın

Topluluk sitesi, insanların onu gerçekten kullanabilmesi halinde işe yarar—yardımcı teknolojilerde, yavaş bağlantılarda ve aramalarda. Erişilebilirlik, performans ve SEO’yu sonradan eklenen bir süs değil, varsayılan kabul edin.

Erişilebilirlik: her seferinde temel seviyeye ulaşın

Anlamsal yapıyla başlayın. Başlıkları sırayla kullanın (sayfada H1 sonra H2/H3) ve sadece daha büyük yazı için seviyeleri atlamayın.

Metin olmayan içerik için anlamlı alt metin zorunlu kılın. Basit bir kural: bir resim bilgi aktarıyorsa açıklayın; sadece dekoratifse boş alt (alt="") kullanın ki ekran okuyucular atlasın.

Renk kontrastı ve focus durumlarını tasarım token’larınızda kontrol edin. Her etkileşimli öğenin klavye ile erişilebilir olduğundan ve menüler, dialoglar veya kod örneklerinde focus tuzağı olmadığından emin olun.

Performans: sayfayı hafif tutun

Görselleri varsayılan olarak optimize edin: maksimum gösterim boyutuna göre yeniden boyutlandırın, sıkıştırın ve build destekliyorsa modern formatları tercih edin. Çoğunlukla metin olan sayfalar için büyük client-side paketleri yüklemekten kaçının.

Üçüncü taraf scriptleri minimumda tutun. Her ekstra widget siteyi yavaşlatır ve herkes için maliyet artırır.

Hostunuzun sağladığı cache varsayılanlarına güvenin (ör. hash’li değişmez varlıklar). Statik site üreticiniz destekliyorsa minify edilmiş CSS/JS üretin ve sadece gerçekten kritik olanı inline edin.

Keşfedilebilirlik: işe yarayan basit SEO

Her sayfaya net bir başlık ve kısa bir meta açıklama verin. Temiz, stabil URL’ler kullanın (tarihler yalnızca gerekiyorsa olsun). Site haritası ve indekslemeye izin veren bir robots.txt oluşturun. Birden fazla doküman versiyonu yayıyorsanız, yinelenen içerikten kaçınmak için bir sürümü “güncel” yapın ve diğerlerine açıkça bağlantı verin.

Analitik ve lisanslama: şeffaf olun

Analitik ekleyin sadece veriyi kullanacaksanız. Ekliyorsanız, hangi verilerin toplandığını, neden toplandığını ve nasıl opt‑out yapılacağını bir sayfada açıklayın (ör. /privacy).

Son olarak, site içeriği için açık bir lisans bildirimi (kod lisansından ayrıysa) ekleyin. Footer’da ve repository README’sinde belirtin ki katkıcılar metin ve görsellerinin nasıl yeniden kullanılabileceğini bilsin.

İnsanların katılmasına yardımcı olacak temel sayfaları oluşturun

Siteinizin temel sayfaları yeni katkıcılar için “gelen yüz”tür. Eğer bu sayfalar hızlıca açık yanıtlar verirse—projenin ne olduğu, nasıl denenebileceği ve nerede yardım gerektiği—daha fazla insan merakı eyleme dönüştürecektir.

Onboarding ile başlayın: “Bu proje nedir?” ve “Quickstart”

Projenin ne yaptığını, kime yönelik olduğunu ve başarı kavramının ne olduğunu açık, sade bir dille anlatan bir özet sayfası oluşturun. Birkaç somut örnek ve “Bu sizin için mi?” kısa bölümü ekleyin.

Ardından momentum için optimize edilmiş bir Quickstart sayfası ekleyin: ilk başarılı çalıştırmaya götüren tek bir yol, kopyala-yapıştır komutlar ve kısa bir sorun giderme bloğu. Kurulum platforma göre değişiyorsa, ana yolu kısa tutup detaylı rehberlere bağlayın.

Önerilen sayfalar:

• /docs/overview — “Bu proje nedir?”
• /docs/quickstart — en kısa çalışan yol

Doğru işe yönlendiren bir “Contribute” merkezi oluşturun

Tek bir /contribute sayfası şu yönlendirmeleri yapmalı:

• Good first issues (filtrelenmiş issue listesine bağlantı)
• Dokümantasyon görevleri (/docs/contributing veya etiketli issue kuyruğu)
• Çeviri/yerelleştirme çalışması (locale ekleme, dizelerin nerede olduğu)

Spesifik olun: bu ay yapılmasını istediğiniz 3–5 görevi adlandırın ve ilgili issue’lara doğrudan bağlantı verin.

Topluluk sayfaları beklentileri belirlesin

Temel belgeleri site üzerinde yayınlayın, repoda gömülü bırakmayın:

• Code of Conduct (ve nasıl raporlanacağı)
• Sohbet/topluluk linkleri (Discord/Matrix/Slack) ve yanıt süresi beklentileri
• Toplantı notları arşivi (ör. /community/meetings)

Tekrar edilebilir şablonla sürüm notları/değişiklik günlüğü

/changelog (veya /releases) ekleyin; tutarlı bir format kullanın: tarih, öne çıkanlar, yükseltme notları ve PR/issue linkleri. Şablonlar bakıcı yükünü azaltır ve topluluk tarafından yazılan notları incelemeyi kolaylaştırır.

Benimseyenler/eklenti gösterimi—sadece güncel tutabilecekseniz

Bir showcase sayfası katkıyı motive edebilir, ama güncelliğini yitiren listeler güvenilirliği zedeler. Eğer /community/showcase eklerseniz, hafif bir kural koyun (örn. “üç ayda bir gözden geçir”) ve küçük bir gönderim formu veya PR şablonu sağlayın.

Sürekli topluluk güncellemelerini ve yerelleştirmeyi destekleyin

Güncellemeler kolay, güvenli ve ödüllendirici olmalı—ilk defa katkıda bulunanlar için bile. Amaç, “nereye tıklamalıyım?” sürtünmesini azaltmak ve küçük iyileştirmelerin değerli hissettirmesini sağlamaktır.

Her sayfanın tek tıkla düzenlenebilir olmasını sağlayın

Dokümanlarda, rehberlerde ve SSS’lerde belirgin bir “Bu sayfayı düzenle” bağlantısı ekleyin. Doğrudan repodaki dosyaya işaret etsin ki PR akışı en az adımdan oluşsun.

Bağlantı metnini dostane tutun (ör. “Yazım hatasını düzelt” veya “Bu sayfayı geliştir”) ve içeriğin üstünde veya altında görünür bir yerde konumlandırın. Eğer katkı rehberi varsa, buradan da bağlayın (örn. /contributing).

Çevirileri basit, öngörülebilir bir yapıyla destekleyin

Yerelleştirme, klasör yapısının bir bakışta soruyu cevapladığı zaman en iyi çalışır. Yaygın yapı:

• /docs/en/…
• /docs/es/…
• /docs/ja/…

İnceleme adımlarını belgeleyin: kim çevirileri onaylayabilir, kısmi çevirileri nasıl ele alırsınız ve hangi çevirilerin güncel olmadığı nasıl takip edilir. Kaynak dilden geride kalan çevirilerin başında kısa bir not göstermeyi düşünün.

“Latest vs stable” rehberliği ekleyin (gerekliyse versiyonlu dokümanlar)

Projeniz sürüm yayıyorsa, kullanıcıların ne okuyacaklarını açıkça belirtin:

• “Latest” güncel geliştirme için
• “Stable” en son kararlı sürüm için

Tam doküman versiyonlaması olmasa bile, farkı açıklayan küçük bir banner veya seçici kafa karışıklığını önler.

SSS ve sorun giderme kolayca güncellenebilir olsun

SSS’leri doküman sisteminde tutun (issue yorumlarının içinde değil). /docs/faq gibi görünür bir yere bağlayın ve insanların hatayla karşılaştıklarında düzeltme yapmaya teşvik edin.

Küçük, yüksek etkili katkıları teşvik edin

Hızlı kazanımlar davet edin: yazım düzeltmeleri, daha açıklayıcı örnekler, güncel ekran görüntüleri ve “bu benim için işe yaradı” notları. Bunlar yeni katkıcılar için en iyi başlangıç yollarıdır ve sitenizi düzenli olarak iyileştirir.

Eğer yazma ve bakım çalışmasını teşvik etmek istiyorsanız, neyi neden ödüllendirdiğinizi şeffaf hale getirin. Örneğin bazı ekipler küçük sponsorluklar veya krediler sunar; Koder.ai’in platform hakkındaki içerik oluşturma için “kredi kazan” programı ilham verebilir ve hafif, topluluk-dostu ödül sistemleri için uyarlanabilir.

Bakıcıları tükenmeden siteyi yönetin

Topluluk odaklı bir site davetkâr olmalı—ama birkaç kişinin sürekli temizlik yapmasının bedelini ödememeli. Amaç, bakım işlerini öngörülebilir, hafif ve paylaşılabilir hale getirmektir.

Basit bakım rutinleri belirleyin

Herkesin hatırlayabileceği bir ritim seçin ve otomatikleştirebileceğiniz işleri otomatikleştirin.

• Haftalık (otomatik): kırık link kontrolleri, temel yazım denetimi ve CI’de build testleri.
• Aylık (15–30 dakika): açık site PR’lerini/issue’larını gözden geçirin, küçük düzeltmeleri birleştirin, bayat konuları nazikçe kapatın.
• Çeyreklik: statik site üreticisi ve eklentiler için bağımlılık güncellemeleri ve hızlı bir erişilebilirlik kontrolü.

Bu takvimi /CONTRIBUTING.md içinde belgeleyin; böylece başkaları güvenle adım atabilir.

İçerik kararları için yönetişim belirleyin

İçerik anlaşmazlıkları normaldir: ton, isimlendirme, ana sayfaya ne koyulacağı veya bir blog yazısının “resmi” olup olmadığı gibi. Uzun süren tartışmalardan kaçınmak için şunları yazın:

• Kimlerin nihai editoryal onaya sahip olduğu (ör. “Website Maintainers” veya dönen bir editör)
• Anlaşmazlıkların nasıl çözüleceği (zaman kutulu tartışma, alternatifler öner, sonra karar)
• Neyin “resmi” olduğunu ve neyin “topluluk” içeriği olduğunu belirleyin

Bu kontrol değil, açıklık içindir.

Hafif bir içerik takvimi tutun

Takvim karmaşık olmak zorunda değil. Tek bir issue (veya basit bir markdown dosyası) ile yaklaşanları listeleyin:

• sürümler
• etkinlikler/sunumlar
• güvenlik duyuruları
• aylık proje güncellemeleri

Bunu blog/haber planlama notlarından bağlayın ki katkıcılar kendileri görev alabilsin.

Yenilerin yardım etmesini kolaylaştırın

Tekrarlayan site konularını (yazım hataları, eski ekran görüntüleri, eksik linkler, erişilebilirlik düzeltmeleri) takip edin ve bunları “good first issue” etiketiyle işaretleyin. Kabul kriterlerini açık yazın: “bir sayfayı güncelle + formatlayıcıyı çalıştır + sonucu ekran görüntüle.”

Yerel kurulum için sorun giderme ekleyin

Dokümanlarınıza kısa bir “Yaygın yerel kurulum sorunları” bölümü ekleyin. Örnek:

# clean install
rm -rf node_modules
npm ci
npm run dev

Ayrıca sık görülen 2–3 hatayı (yanlış Node sürümü, eksik Ruby/Python bağımlılığı, port kullanımda) not edin. Bu, geri dönüşleri azaltır ve bakıcı enerjisini korur.