Kamu Karar Geçmişi İçin Bir Web Sitesi Nasıl Kurulur

Bir Kamu Karar Geçmişi Nedir (ve Ne Değildir)

Bir kamu karar geçmişi, anlamlı ürün kararlarının küratörlü bir kaydıdır — web sitenizde yayımlanır — böylece insanlar ne seçtiğinizi, ne zaman seçtiğinizi ve o zaman neden mantıklı olduğunu anlayabilir.

Bunu dokümantasyonunuz ve değişiklik günlüğünüzün yanında duran bir “gerekçe katmanı” olarak düşünün. Pazarlama yazısı değildir ve toplantı transkripti de değildir. Tahmini azaltan, hizalanmayı hızlandıran ve aynı tartışmaların birkaç ayda bir yeniden başlamasını önleyen pratik bir referanstır.

Nedir

İyi bir kamu karar geçmişi:

• Kullanıcıları veya katkıda bulunanları etkileyen kararları kaydeder (özellikler, kullanım dışı bırakmalar, fiyatlandırma modeli değişiklikleri, güvenlik duruşu değişiklikleri, API ilkeleri, UX konvansiyonları)
• Bağlamı ve kısıtları açıklar (müşteri ihtiyaçları, düzenleyici gereksinimler, teknik sınırlamalar, zamanlama)
• Değerlendirilen seçenekleri ve kabul ettiğiniz ödünleri belirtir
• Birisi “Neden böyle yaptınız?” diye sorduğunda kolayca gösterilebilecek sabit bir URL sağlar

Ne değildir

Beklentileri ayarlamak için neyi yayımlamadığınızı açıkça belirtin:

• Her iç konuşma değil: bu bir sonuç günlüğüdür, Slack, aramalar veya tartışma dizilerinin tekrar oynatımı değil.
• Gelecek işler için bir vaat değil: yapılan kararları kaydeder, bir yol haritası değildir.
• Hassas detaylar için bir yer değil: müşteri bilgileri, açıklıklar veya iç metrikler ifşa edilmeden gerekçe açıklanabilir.

Neden yayımlanır (pratik hedefler)

Çoğu ekip bir kamu karar geçmişini şu amaçlarla yayımlar:

• Tutarlılığı göstererek güven inşa etmek
• Müşteriler, ortaklar ve yeni ekip arkadaşları için oriyantasyonu hızlandırmak
• Kanonik bir girdiye bağlayarak tekrar eden tartışmaları azaltmak (“Bunu zaten kararlaştırdık”)

Kimin için

Hedef okuyucularınız genellikle şunları içerir:

• Uygunluğu ve uzun vadeli yönü değerlendiren müşteriler
• Ürününüzle entegre olan ortaklar
• Standartlarda hizalanan katkıda bulunanlar (açık kaynak veya topluluk)
• Birincil kaynaklar arayan basın ve analistler

Birincil okuyucunuzu isimlendirebilirseniz, girdileriniz daha kısa, daha net ve daha faydalı olur.

Kapsam: Hangi Kararlar Yayımlanmalı

Bir kamu karar geçmişi, okuyucuların ne bulacaklarını tahmin edebildiği zaman en iyi şekilde çalışır. Her şeyi yayımlarsanız site gürültülü olur; sadece “başarıları” yayımlarsanız pazarlama gibi görünür. Ekibiniz için tutarlı, kullanışlı ve sürdürülebilir bir kapsam tanımlayın.

Karar türlerinizi adlandırarak başlayın

Yakalamak istediğiniz kategorileri listeleyin ve her biri için basit bir kural yazın. Yaygın türler şunlardır:

• Ürün özellikleri: bir özelliği neden eklediğiniz (veya kaldırdığınız) ve hangi problemi çözdüğü
• Fiyatlandırma ve paketleme: plan değişiklikleri, limitler, denemeler, indirim politikası
• Güvenlik ve gizlilik: anlamlı iyileştirmeler, ödünler ve müşteri açısından etkiler
• UX ve tasarım: büyük etkileşim değişiklikleri, erişilebilirlik kararları, navigasyon değişiklikleri

İyi bir test: bir müşteri “bunu neden yaptınız?” diye sorabilirse, muhtemelen yayınlanmalıdır.

Sürdürebileceğiniz bir zaman aralığı seçin

Kararları hangi dönemden itibaren yayımlayacağınızı belirleyin:

• Kuruluş anından itibaren (yeni ürünler için ideal)
• Belirli bir kilometre taşından itibaren (ör. “v2.0 ve sonrası”)
• Sadece büyük sürümler için (pragmatik bir başlangıç noktası)

Geçmişi geriye dönük dolduruyorsanız, net bir kesme noktası seçin ve bunu bir giriş notunda söyleyin. Eksik görünmektense açık olmak daha iyidir.

Doğru ayrıntı düzeyini seçin

Her karar uzun bir anlatı gerektirmez. İki katman kullanın:

• Kısa girdiler: ilgili dokümanlara veya sürümlere bağlantılarla 3–6 cümlelik özet
• Derin yazılar: yüksek etkili kararlar için (fiyatlandırma, kırıcı değişiklikler, güven/safety)

Tutarlılık uzunluktan daha önemlidir; okuyucular güvenilir bir format ister.

Neyin özel kalacağını tanımlayın

Olay bazlı tartışmalardan kaçınmak için başlangıçta hariç tutulanları yazın:

• Güvenlikle ilgili hassas ayrıntılar (saldırı yolları, iç kontroller)
• Kişisel veriler (müşteriler, çalışanlar, röportaj notları)
• Sözleşme ve müzakere detayları
• Kötüye kullanılabilecek dahili metrikler

Detayları gizlemek zorunda kaldığınızda, girdiyi kısa bir “Paylaşabildiklerimiz” notuyla yayınlayın ki giriş yine dürüst ve tamamlayıcı hissedilsin.

Karar Girişi Şablonu ve Zorunlu Alanlar

Bir kamu karar geçmişi yalnızca her giriş aynı temel soruları yanıtlıyorsa işe yarar. Okuyucular hangi problemi çözdüğünüzü, neleri değerlendirdiğinizi veya karar verildikten sonra neyin değiştiğini tahmin etmeye çalışmamalı.

Temel şablon (Bağlam → Seçenekler → Karar → Gerekçe → Etki)

Her karar sayfası için tutarlı bir yapı kullanın. Tekrarlanabilir akış yazarları disipline eder ve taramayı kolaylaştırır:

• Bağlam: Kararı tetikleyen nedir? Kısıtlamaları (zaman, bütçe, politika), kullanıcı ihtiyaçlarını ve ilgili arka planı dahil edin.
• Seçenekler: Değerlendirdiğiniz gerçek alternatifler (genellikle 2–4). Kısa olarak ödünleri not edin.
• Karar: Seçilen seçenek, açıkça ifade edilmiş.
• Gerekçe: Bu seçeneğin neden kazandığı. Ana faktörleri ve varsayımları içirin.
• Etki: Karardan sonra ne değişti—kullanıcıya görünen davranış, iç süreçler, kullanım dışı bırakmalar veya yeni riskler.

Sıralanabilir ve güvenilir kılmak için zorunlu metadata

Her girişin üstünde küçük bir “başlık” bloğu alanı ekleyin:

• Tarih (isteğe bağlı olarak “kararın yürürlük tarihi” farklıysa onu da)
• Durum: önerildi / kabul edildi / geri alındı (veya yerine geçti)
• Sahipler: sorumlu kişi/ekip (her zaman yazardan farklı olmak zorunda değil)
• Etiketler: ürün alanı, müşteri segmenti, platform vb.
• Hedef kitle (isteğe bağlı): kimlerin dikkat etmesi gerektiği—müşteriler, ortaklar, dahili kullanıcılar

Bu metadata daha sonra filtreler ve zaman çizelgeleri için güç sağlar ve kararın ne kadar nihai olduğunu gösterir.

İnsanların doğrulayabileceği şeylere bağlayın

Bir karar, okuyucuların çıktılara ve kanıtlara iz sürmesini sağlayınca daha inandırıcı olur:

• İlgili değişiklik günlüğü girdisine bağlantı (ör. /changelog/2025-04-18-search-update)
• Destekleyici dokümantasyona bağlantı (ör. /docs/search/indexing)
• Sürüm notu veya versiyon sayfasına bağlantı (ör. /releases/1.12)

Geri alma ve “yerine geçme” planı

Geri almalar normaldir—bunları açıkça yayımlayın. Bir karar değiştirdiğinde:

• Durumu geri alındı veya yerine geçti olarak değiştirin
• Yerine geçen yeni girdiye (ör. /decisions/014-new-rate-limits) bağlantı ekleyin
• Kısa bir Neden değişti paragrafı ekleyin (yeni veriler, beklenmeyen maliyetler, politika değişikliği)

Bu, karar zaman çizelgenizi dürüst tutar ve geçmişi yeniden yazmadan ilerlemenizi sağlar.

Bilgi Mimarisi ve Navigasyon

Bir kamu karar geçmişi yalnızca okuyucuların iki soruyu hızlıca yanıtlayabildiği sürece işe yarar: “Ne oldu?” ve “Bu konuyu açıklayan kararı nerede bulurum?” Bilgi mimariniz, daha önce ürününüzü görmemiş biri için bile gezinmeyi açık hale getirmeli.

İnsanların nasıl aradığına uyan bir birincil navigasyon seçin

Çoğu ekip için en iyi sonuç veren 3–4 üst düzey öğedir; farklı okuma stillerini kapsar:

• Zaman çizelgesi — baştan sonra hikâyeyi takip edenler için kronolojik görünüm.
• Konular/Etiketler — “Fiyatlandırma”, “API”, “Erişilebilirlik” veya “Güvenlik” gibi temalara atlamak için yol.
• Ana Kararlar — sıkça referans verilen veya dışarıdan sık sorulan kararların küratörlü listesi.
• Hakkında — bu sitenin ne olduğu, neleri içerdiği/etkilemediği ve girişlerin nasıl yorumlanacağı.

Üst navigasyonu sabit tutun. Daha sonra yeni sayfalar ekleyecekseniz (ör. “Metodoloji”), bunları Ana menüyü genişletmek yerine Hakkında altında toplayın.

URL desenlerine karar verin (ve sonra değiştirmeyin)

Net URL’ler siteyi paylaşmayı, alıntılamayı ve aramayı kolaylaştırır. İyi çalışan basit bir desen örneği:

• /decisions/2025-03-feature-flags

Sıralama için tarihler ve kısa, insan tarafından okunabilir bir slug kullanın. Ayda birçok karar bekliyorsanız günü de ekleyin (/decisions/2025-03-18-feature-flags). Yayınladıktan sonra URL’leri yeniden adlandırmaktan kaçının; zorunluysa yönlendirmeler ekleyin.

“Buradan başla” sayfası ekleyin

Kısa bir rehber kafa karışıklığını azaltır ve taslakları veya eksik kayıtları yanlış yorumlamayı önler. Başlık ve Hakkında’dan bağlantılı belirgin bir sayfa oluşturun (ör. /start-here) ve şu konuları açıklayın:

• Bu sitede neyin “karar” sayıldığı
• etiketleri, aramayı ve filtreleri nasıl kullanacağınız
• “Durum” etiketlerinin ne anlama geldiği (örn. Proposed, Accepted, Reversed)
• güncellemeleri ve revizyonları nasıl yorumlayacağınız

Öncelikle taramaya, sonra derinliğe göre tasarlayın

Çoğu ziyaretçi göz tarar. Her karar sayfasını şu şekilde yapılandırın ki temel bilgiler hemen görünür olsun:

• bir paragraflık özet (ne değişti ve neden)
• üstte görünür ana metadata (tarih, durum, sahip)
• detaylı gerekçe aşağıda, katlanıp açılabilecek bölümlerle

Listelerde (Zaman çizelgesi, Konular) başlık, tarih ve 1–2 satırlık özet gösteren “kart tarzı” önizlemeler gösterin. Bu, okuyucuların her girdiyi açmadan hızlıca gezmesini sağlar; tam detay ise tek tıkla erişilebilir olsun.

Veri Modeli: Kararları Nasıl Saklamalı

Bir kamu karar geçmişi, altta yatan yapısı kadar faydalıdır. Eğer okuyucular bir karara güvenilir biçimde bağlanamazsa, filtreleyemezse veya neyle ilişkili olduğunu anlayamazsa site hızla bir gönderi yığınına döner.

Ekibinize uyan en basit depolamayı seçin

Genel olarak üç seçeneğiniz olur:

• Repoda Markdown dosyaları: versiyonlama, inceleme ve düşük maliyet için harika. Statik site oluşturucularla iyi çalışır ve Git tabanlı iş akışıyla uyumludur.
• CMS girdileri: teknik olmayan editörler için ve dahili taslak/onaylar için daha kolay, ancak URL’leri ve dışa aktarımları kontrol etmek isteyeceksiniz.
• Veritabanı kayıtları (özel uygulama): karmaşık ilişkiler ve analizler için en iyi, ancak en yüksek bakım maliyeti.

İleri düzey ilişkilere (ürünler, sürümler ve müşteri segmentleri arasında çoktan-çoğa bağlantılar gibi) ihtiyacınız yoksa Markdown veya CMS ile başlayın.

Kırılmamış bağlantılar için kalıcı bir benzersiz ID kullanın

Her kararı kalıcı bir kayıt gibi ele alın. Başlık değişse bile asla değişmeyecek sabit bir karar ID atayın.

Örnek formatlar:

• DEC-00127
• PDH-2025-04-15-analytics-export

ID’yi URL’de (veya bir parçası olarak) kullanın ki destek ticket’ları, dokümanlar veya blog gönderilerinden gelen bağlantıları yeniden adlandırmak zorunda kalmayın.

Filtreleme ve navigasyonu güçlendirecek alanları modelleyin

Her alanı herkese açık göstermeseniz bile baştan tanımlayın ki sonradan filtreler oluşturabilesiniz. Yaygın alanlar şunlardır:

• Ürün alanı (ör. Billing, Reporting)
• Müşteri segmenti (ör. SMB, Enterprise)
• Durum (Proposed, Decided, Revisited)
• Sürüm (versiyon, tarih veya /changelog bağlantısı)
• Karar tarihi ve yürürlük tarihi
• Etiketler (gizlilik, fiyatlandırma, performans)

Ekleri nasıl saklayacağınızı planlayın

Diyagramlar, ekran görüntüleri ve PDF’lerin nerede duracağını belirleyin:

• Hafif görselleri karar girdisinin yanında tutun (ör. /assets/decisions/DEC-00127/ klasörü).
• PDF veya büyük dosyalar için kalıcı bir dosya yolu kullanın ve dosyaları karar ID ile adlandırın.

Seçiminiz ne olursa olsun, ek dosya URL’lerini öngörülebilir yapın ki site evrildikçe bozulmasın.

Araç Seçimleri: Statik Site, CMS veya Özel Uygulama

Araç setiniz iki şeye uymalı: kararları ne sıklıkla yayımladığınız ve ne kadar “okuyucu deneyimi” (arama, filtreler, ilişkiler) gerektiği. Çoğu ekip basit başlayıp arşiv büyüdükçe daha karmaşık çözüme geçer.

Seçenek 1: Statik site (hızlı, düşük bakım)

Bir statik site oluşturucu (örneğin doküman tarzı site) Markdown dosyalarını hızlı bir web sitesine çevirir. Bu, bir kamu karar geçmişi başlatmanın genellikle en kolay yoludur.

Aşağıdaki durumlarda iyi çalışır:

• Kararları ara sıra veya öngörülebilir bir tempoda yayımlıyorsanız
• Filtreleme ihtiyaçlarınız temel düzeydeyse (ürün alanı, tarih, durum)
• Düşük operasyonel yük istiyorsanız (sunucu yok, daha az parça)

Statik siteler ayrıca “kararlar olarak kod” yaklaşımıyla iyi oynar: her karar girdisi repodaki bir Markdown dosyasıdır, pull request ile gözden geçirilir. Yüksek kaliteli tam metin arama istiyorsanız barındırılan bir arama sağlayıcıyla eşleştirin.

Seçenek 2: Git tabanlı Markdown vs headless CMS

Git tabanlı Markdown, katkıda bulunanlar pull request konusunda rahatsa ve net bir denetim izi isteniyorsa harikadır. İncelemeler, onaylar ve geçmiş zaten mevcuttur.

Bir headless CMS, birçok yazar teknik değilse veya formda zorunlu alanlar (karar türü, etki seviyesi, etiketler) gerekiyorsa daha iyidir. Yine statik site’ye yayınlarsınız, ama düzenleme CMS içinde yapılır.

Seçenek 3: Özel uygulama (gelişmiş filtreleme ve ilişkiler)

Zengin filtreleme (çoklu seçim yüzeyleri, karmaşık sorgular), çapraz bağlantılama (kararlar ↔ sürümler ↔ dokümanlar) ve kişiselleştirilmiş görünümler gerektiğinde özel uygulama mantıklıdır. Maliyet, sürekli mühendislik ve güvenlik çalışmasıdır.

Hızlı bir inşa döngüsü olmadan özel uygulamanın faydalarını istiyorsanız, bir “vibe-coding” iş akışı pratik bir ara yol olabilir: veri modeli (karar girdileri, etiketler, durum, yerine geçer bağlantılar), sayfalar (Zaman çizelgesi, Konular, Ana Kararlar) ve yönetim iş akışını tanımlayıp hızlıca yineleyin.

Örneğin, Koder.ai sohbet tabanlı planlama ve inşa süreciyle ekiplerin karar-geçmişi sitesi veya hafif bir özel uygulama oluşturmasına yardımcı olabilir — webde React, Go servisleri ve altta PostgreSQL kullanırken — aynı zamanda dışa aktarılabilir bir kod tabanı ve öngörülebilir URL’ler sağlar. Bu, filtreler, arama, önizlemeler ve rol tabanlı yayınlama istiyorsanız, tam bir dahili platform yeniden yazımına girmeden faydalıdır.

Arama ve önizleme ortamları

Arama için şu seçeneklerden birini seçin:

• Yerleşik site araması (kurulumu hızlı, sınırlı)
• Barındırılan arama (en iyi alaka ve filtreleme)
• Sunucu tarafı arama (en fazla kontrol, en yüksek bakım)

Hangi yolu seçerseniz seçin, gözden geçiricilerin girdiyi yayımlanmadan önce tam olarak nasıl görüneceğini görebildiği önizleme derlemeleri kurun. Taslağa eklenen basit bir “önizleme” bağlantısı yeniden işi azaltır ve yönetişimin hafif kalmasına yardımcı olur.

Arama, Filtreler ve Okuyucu Deneyimi

Bir kamu karar geçmişi yalnızca insanların ilgilendikleri kararı hızlıca bulabildiği ve her şeyi okumadan anlayabildiği sürece işe yarar. Arama ve navigasyonu bir dekorasyon değil ürün özelliği olarak ele alın.

Niyeti anlayan tam metin arama

Başlangıç olarak başlıklar, özetler ve “Karar”, “Durum” ve “Gerekçe” gibi ana alanlar üzerinden tam metin arama sağlayın. İnsanlar nadiren iç terminolojinizi bilir, bu yüzden arama kısmi eşleşmeleri ve eşanlamlıları tolere etmelidir.

Aramayı, okuyucuların sonuçları hızla daraltması için filtrelerle eşleştirin:

• Etiket (örn. “fiyatlandırma”, “API”, “gizlilik”)
• Durum (önerildi, kabul edildi, geri alındı, kullanımdan kaldırıldı)
• Tarih aralığı (çeyrek, yıl, özel)
• Alan/sahip (ekip, ürün yüzeyi, bölge)

Filtreleri masaüstünde görünür ve mobilde kolay açılır/kapanır yapın. Aktif filtreleri kaldırılabilir “etiketler” olarak gösterin ve her zaman tek tıkla “Tümünü temizle” seçeneği bulundurun.

Bağlam için çapraz bağlantı, karışıklık için değil

Çoğu okuyucu bir changelog, destek bileti veya sosyal gönderiden gelir. Onlara bağlam oluşturmayı kolaylaştırın, kararları şunlara bağlayarak:

• İlgili kararlar (bağımlılıklar, alternatifler, “yerine geçti/yerine geçen”)
• Sonuçlar (metrikler, öğrenimler, takip eylemleri)
• Destekleyici dokümanlar (sürüm notları, politika sayfaları, SSS)

Bağlantıları amaçlı tutun: bir veya iki “İlgili” öğe uzun bir listeden iyidir. Girdileriniz benzersiz bir ID içeriyorsa, ID ile aramaya izin verin ve başlığın yakınında gösterin ki kolay referans verilebilsin.

“Son ziyaretimden beri ne değişti”

Yeni veya güncellenmiş kararları vurgulayan bir Recent görünümü ekleyin. İki pratik seçenek:

• Güncellenme tarihine göre sıralanmış /decisions/recent sayfası
• Güncellemeler için isteğe bağlı bir RSS/Atom beslemesi (özellikle gazeteciler ve ortaklar için faydalı)

Kullanıcı hesaplarını destekliyorsanız, son ziyarete göre “o zamandan beri” gösterebilirsiniz, ama basit bir recent listesi genellikle çoğu değeri verir.

Erişilebilirlik ve okunabilirlik

H2/H3 gibi net başlık yapısı, güçlü renk kontrastı ve okunabilir font/boyut kullanın. Arama, filtreler ve sayfalama için klavye navigasyonunun çalıştığından ve görünür odak durumlarının sağlandığından emin olun. Özetleri kısa tutun, taranabilir bölümler kullanın ve yoğun metin bloklarından kaçının ki okuyucular kararı bir dakikadan kısa sürede kavrayabilsin.

Yayınlama İş Akışı ve Yönetişim

Bir kamu karar geçmişi, girdilerin eksiksiz, tutarlı ve özenle yazıldığını okuyucuların güvenebilmesi için işe yarar. Ağır bürokrasi gerekmez, ama taslaktan yayımlamaya kadar tekrarlanabilir bir yol ve net sahiplik gerekir.

Rolleri tanımlayın (aynı kişi iki şapka taksa bile)

Her giriş için kim ne yapar belirleyin:

• Yazar: kararı yazar, bağlamı açıklar, destek materyallerine bağlantı verir ve son metni önerir.
• İnceleyici: açıklık ve bütünlüğü denetler, varsayımları sorgular ve bağlantıların doğruluğunu onaylar.
• Onaylayıcı: kararın gerçek, güncel ve iç onaylarla uyumlu olduğunu doğrular (örn. ürün liderliği, güvenlik, hukuk).
• Yayıncı: girdinin yayınlama standardını karşıladığından emin olur, etiket/durum uygular ve siteye yayınlar.

Bu rolleri her girdi üzerinde görünür tutun (ör. “Yazar / İnceleyici / Onaylayıcı”) ki süreç şeffaf olsun.

Hafif bir ön-yayın kontrol listesi kullanın

Kısa bir kontrol listesi çoğu kalite sorununu yavaşlatmadan önler:

• Açıklık: Bir uzman olmayan kişi bir kez okuduktan sonra kararı özetleyebiliyor mu?
• Bağlantılar: İlgili dokümanlara, ticket’lara, araştırmalara veya sürümlere bağlantılar var mı?
• Hassas bilgi: Müşteri verisi, güvenlik detayları, sözleşme koşulları veya yalnızca dahili planlar açığa çıkıyor mu?
• Ton: Tarafsız ve olgusal mı (suçlama yok, alay yok) ve ödünler adil şekilde açıklanmış mı?

Daha sonra şablonlar oluşturursanız, bu kontrol listesini taslağa gömün.

Düzenleme kuralları: hataları düzeltin ama geçmişi yeniden yazmayın

Kararlar tarihsel kayıtlardır. Bir şey düzeltmeniz gerektiğinde, ekleyici değişiklikleri tercih edin:

• Yazım/format düzeltmelerini sessizce yapın.
• Gerçek düzeltmeler için kısa bir “Güncelleme” notu tarih ve yapılan değişiklikle ekleyin.
• Eğer karar değiştiyse, eski sonucu düzenlemek yerine yeni bir karar girdisi yayınlayın ve eskisine bağlantı verin (“Yerine geçti …”).

Yazım standartlarınızı yayınlayın

Kısa bir rehber sayfası ekleyin (ör. /docs/decision-writing) ve şunları açıklayın:

• neyin yayımlanabilir karar sayıldığı,
• beklenen yapı ve sözcük kullanımı,
• belirsizliği ve ödünleri nasıl ele alacağınız,
• yukarıdaki düzenleme politikası.

Bu, daha fazla kişi katkıda bulunduğunda sesi tutarlı tutar ve zamanla inceleyici yükünü azaltır.

Gizlilik, Güvenlik ve Hukuki Hususlar

Karar gerekçesini yayımlamak güven oluşturur, ama yanlışlıkla paylaşma riskini de artırır. Kamu karar geçmişinizi ham iç notların dışa aktarımı değil, küratörlü bir eser olarak ele alın.

Kırpma (redaksiyon): asla halka açılmayacakları belirleyin

Net bir redaksiyon kural setiyle başlayın ve bunu tutarlı uygulayın. Yaygın “her zaman kaldırılacak” öğeler şunlardır: kişisel veriler (isimler, e-postalar, çağrı transkriptleri), özel müşteri detayları (hesap bilgileri, sözleşme koşulları, yenileme tarihleri), kötüye kullanıma yol açabilecek şeyler (güvenlik bulguları, hassas sistem diyagramları, dahili admin URL’leri).

Bir karar hassas girdilerle şekillendiyse, yine de gerekçenin şeklini şeffaf şekilde paylaşabilirsiniz:

• Kanıtı özetleyin (“Destek, AB kartlarında tekrar eden ödeme hataları bildirdi”) yerine ticket’lardan doğrudan alıntı yapmaktan kaçının.
• Tanımlayıcıları geniş kategorilerle değiştirin (“kurumsal müşteri” vs. şirket adı).
• Tüm girişleri atlamaktansa “güvenlik ekibinin önerisi—detaylar paylaşılmadı” gibi ertelemeler kullanın.

Hukuk/uyumluluk incelemesi: hafif bir kapı

Her karar hukuki inceleme gerektirmez, ama bazıları ister. Fiyat değişiklikleri, düzenlenen sektörler, erişilebilirlik iddiaları, gizlilik politikası etkileri veya ortak anlaşmaları gibi konular için tanımlı bir “inceleme gerekli” bayrağı belirleyin.

Adımı basit tutun: bir kontrol listesi ve atanmış bir inceleyici, bekleme süreleriyle. Amaç, yayınlamayı dondurmadan önlenebilir riskleri engellemektir.

Nelerin kasıtlı olarak hariç bırakıldığını açıkça belirtin

Hakkında sayfanızda veya altbilgide kısaca neyi yayımlamadığınızı ve nedenini açıklayan bir politika notu ekleyin: kullanıcıları korumak, sözleşmelere saygı göstermek ve güvenlik açıklığını azaltmak. Bu, okuyucular boşluklar fark ettiğinde spekülasyonu azaltır.

Düzeltme ve endişe bildirme yolu oluşturun

Okuyucuların sorun bildirmesi, düzeltme istemesi veya gizlilik endişesi iletmesi için net bir yol verin. İletişim için /contact gibi ayrılmış bir kanal belirleyin ve yanıt penceresi taahhüt edin. Ayrıca kaldırma taleplerini nasıl ele aldığınızı ve revizyonların nasıl not edildiğini belgeleyin (örn. “2026-01-10 tarihinde müşteri tanımlayıcılarını kaldırmak üzere güncellendi”).

Kararları Sürümler, Dokümanlar ve Sonuçlarla Bağlama

Bir karar sayfası, insanların görebileceği ve doğrulayabileceği şeylere bağlandığında en kullanışlıdır: ne yayınlandı, ne değişti ve sonrasında ne oldu. Her kararı sürümlere, dokümanlara ve gerçek dünya sonuçlarına işaret eden bir merkez olarak ele alın.

Kararları sürümlere ve changelog’a bağlayın

Her karar girişine küçük bir “Shipped in” bloğu ekleyin ve ilgili sürüm notlarına (ör. /changelog) bir veya daha fazla bağlantı verin. Yayın tarihi ve versiyon (veya sprint adı) ekleyin ki okuyucular gerekçeyi gerçeğe bağlayabilsin.

Bir karar birden fazla sürümü kapsıyorsa (fazlı dağıtımlar yaygındır), bunları sırayla listeleyin ve her fazda neyin değiştiğini açıklayın.

“İlgili dokümanlar” bağlantılarını koruyun

Kararlar genellikle “neden”i cevaplar, dokümanlar ise “nasıl”ı. Karar girdilerine bu karardan dolayı oluşturulan veya güncellenen /docs sayfalarına bağlantı veren bir “İlgili dokümanlar” bölümü ekleyin (kurulum rehberleri, SSS, API referansları).

Bu bağlantıların bozulmaması için:

• Yayınlama iş akışının bir parçası olarak “doküman bağlantısı kontrolü” yapın (hatta üç aylık tarama bile yardımcı olur).
• Kalıcı doküman URL’lerini tercih edin (tarih bazlı slug’lardan kaçının).

Niyet değil sonuçları gösterin

Yayın sonrası güncelleyeceğiniz bir “Outcomes” bölümü ekleyin. Olgusal tutun:

• İzlediğiniz metrikler (örn. destek ticket sayısı, aktivasyon oranı, tamamlama süresi)
• Alınan geri bildirimler (özetlenmiş temalar, ham özel alıntılar değil)
• Takip görevleri (varsa kamuya açık issue bağlantıları veya kısa bir durum listesi)

Hatta “Sonuç: karışık” demek bile güven oluşturur; ne öğrendiğinizi ve sonrasında ne değiştirdiğinizi açıklayın.

“En çok referans verilen kararlar” dizini oluşturun

Oryantasyon için, “En çok referans verilen kararlar” listesi (veya kenar çubuğu modülü) ekleyin. İç bağlantılar, sayfa görüntüleme sayısı veya dokümanlar ve /changelog girdilerinden gelen atıf sayısına göre sıralayın. Bu, yeni okuyuculara ürünün en çok etki eden kararlarına hızlı yol verir.

Etkiyi Ölçme ve Yineleme

Bir kamu karar geçmişi yalnızca insanlar cevapları bulabiliyorsa ve bulduklarına güveniyorsa kullanışlıdır. Siteyi bir ürün gibi ele alın: nasıl kullanıldığını ölçün, nerede başarısız olduğunu öğrenin ve küçük, düzenli döngülerle iyileştirin.

İnsanların gerçekte ne kullandığını izleyin

Gösterişli metrikler yerine davranış odaklı hafif analizlerle başlayın. Şuna bakın:

• En çok okunan sayfalar: en çok hangi kararlar okunuyor (daha iyi çapraz bağlantılar ve daha net özetler için adaylar).
• Sonuç vermeyen aramalar: eksik etiketler, belirsiz başlıklar veya olmayan kararların en hızlı keşif yolu.
• Sayfada geçirilen süre ve çıkışlar: uzun okuma yüksek ilgi veya kafa karışıklığı olabilir; bunu geri bildirim ile eşleştirin.

Eğer bir /search sayfanız varsa, aramaları (anonim bile olsa) kaydedin ki insanların ne aradığını görebilin.

Önemli yerlerde geri bildirim toplayın

Bağlam taze iken her karar sayfasında yanıt vermeyi kolaylaştırın. Basit bir “Bu yardımcı oldu mu?” istemi ve kısa bir metin alanı sıklıkla yeterlidir. Alternatif olarak, karar URL’sini ön-dolduran “Bu kararla ilgili soru?” bağlantısı ekleyin.

Geri bildirimi kaybolmaması için paylaşılan bir gelen kutusuna veya takipçiye yönlendirin.

Başarı sinyalleri tanımlayın

Gözlemlenebilir birkaç çıktıyı seçin:

• Aynı konuda tekrarlayan soruların azalması müşteriler/ortaklar/destekten
• Paydaş hizalanmasının hızlanması (örn. geçmiş seçimleri yeniden tartışmak için gereken toplantı döngülerinin azalması)
• Daha kaliteli tartışmalar: geri bildirimlerin gerekçe ve ödünlere referans vererek gelmesi

Pratik bir kadro belirleyin

Aylık bir gözden geçirme planlayın:

• çoğaltılanları budayın veya birleştirin,
• eksik etiketleri ve çapraz bağlantıları ekleyin,
• belirsiz özetleri yeniden yazın,
• aramanın daha iyi çalışması için başlıkları iyileştirin.

Değişiklikleri görünür tutun (örn. “Son güncelleme” alanı) ki okuyucular sitenin terkedilmediğini, bakım gördüğünü anlasınlar.