GitHub’da “Low Quality” Etiketi: Moderasyonda Küçük Ama Yerinde Bir Hamle
Geçenlerde bir müşteride tam da bu konuyu konuşurken şunu fark ettim: her kötü yorum aynı değil. Biri açıkça spam, biri saldırganlaşıyor, bir diğeri işe sadece boş… hani vardır ya, teknik olarak “suç” sayılmaz ama ortama da hiçbir şey katmaz (bu konuda ikircikliyim). GitHub’ın yeni Low Quality seçeneği bence tam buraya oturuyor.
İşin aslı şu ki moderasyon araçları uzun süre siyah-beyaz çalıştı. Ya spam dediniz ya abuse. Ama sahada durum hiç öyle olmuyor. 2024’te bir finans kuruluşunda yaptığımız GitHub Enterprise Cloud düzeninde bunu çok net gördük; ekipler bazen iyi niyetli ama tamamen alakasız yorumlarla boğuşuyordu. Bunları doğru sınıfa koymakta gerçekten zorlanıyordu, kim ne derse desin. Şimdi gelen bu seçenek, biraz daha dürüst bir etiketleme sunuyor.
Neyse uzatmayalım… GitHub’ın yaptığı büyük bir devrim değil. Ama bayağı yerinde bir iyileştirme. Küçük görünüyor, fakat platform yönetişimi tarafında detaylar bazen esas oyunu değiştiriyor — bunu defalarca yaşadım.
Neden böyle bir kategoriye ihtiyaç vardı?
Moderasyon denince çoğu kişi hemen spam veya taciz gibi ağır örnekleri düşünüyor. Haklılar da. Fakat günlük hayatta asıl gürültü çoğu zaman çok daha sönük geliyor: konuyla ilgisiz yorumlar, tek kelimelik tepkiler, tekrar eden boş mesajlar, gereksiz tartışma başlatan ama doğrudan kural ihlali olmayan içerikler… Bunlar ne tam spam ne de abuse. Tam ortada asılı kalıyorlar.
Ben bunu ilk kez 2019’da kendi yönettiğim topluluk tabanlı bir proje forumunda bizzat yaşamıştım. Kullanıcılar sürekli “+1”, “bende de öldü”, “neden çalışmıyor?” gibi mesajlar bırakıyordu — kimseyi banlamak istemezsiniz çünkü adam kötü niyetli değil,. Arama kalitesi düşüyor, konu akışı bozuluyor, moderatörün günü de çöp oluyor (buna dikkat edin). Aynı his şimdi GitHub tarafında da var.
AZ-500 ve AZ-305 çalışırken hep şunu düşünürdüm: güvenlik sadece saldırıyı engellemek değil, düzeni korumak da. Burada da mantık aynı. Platform governance dediğimiz şey biraz kapı kilidi gibi; hırsızı durdurur, ama evin içinde ayakkabıları nereye koyacağınızı da az çok düzenler.
Spam ile düşük kalite aynı şey değil
Eh, Burada ince ama önemli bir ayrım var. Spam genelde dışarıdan gelir; reklam kokar, otomasyon izleri taşır ya da manipülasyon amacı bellidir. Low Quality işe çoğu zaman sistemin tam içinden çıkar: geliştirici topluluğunun yorucu küçük davranışları, bağlamdan kopuk kısa cümleler ya da katkı yerine sadece ses çıkaran içerikler…
Bir telekom müşterimizde 2025’in son çeyreğinde buna benzer bir ayrım yapmıştık; destek portalına gelen yorumların yaklaşık yüzde 18’i ne yanlış ne de zararlıydı, sadece zayıftı. O gün anladım ki yanlış sınıflandırma moderasyonu hantallaştırıyor. İnsanlar doğru etiketi bulamayınca işi erteliyor… sonra yığın büyüyor, büyüyor, büyüyor.
Moderasyonda doğru etiket yoksa süreç yavaşlıyor; süreç yavaşlayınca ekipler etikete değil yoruma bakmaya başlıyor.
GitHub’da yeni seçenek pratikte ne değiştiriyor?
Kullanım akışı basitmiş gibi dürüyor ve aslında öyle: herhangi bir issue, discussion, pull request ya da commit üzerindeki yorumun üç nokta menüsüne giriyorsunuz… Hide comment diyorsunuz… ardından sınıflandırmada Low Quality seçiyorsunuz. Bitti. Bu konuyla ilgili Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için GitHub’un Mart 2026 Dersi: Dayanıklılık Kağıt Üstünde Değil yazımıza bakabilirsiniz.
Ama pratik etkisi hiç basit değil. Çünkü artık moderatörün elinde daha işabetli bir işaret var — bu sayede raporlama tarafında daha temiz veri oluşuyor, trend analizi yapılabiliyor. Sız hiç denediniz mi? Hangi tür içeriklerin topluluğu gerçekten yorduğu çok daha net görülebiliyor.
Küçük ekipte etkisi başka, enterprise’da başka
Küçük bir startup için bu özellik biraz lüks gibi görünebilir. Hani önce ürün çıksın dersiniz ya… orası ayrı mesele! Ama topluluk büyümeye başlayınca moderasyon yükü görünmez şekilde artıyor. Bu ne anlama geliyor? O zaman böyle ince kategoriler hayat kurtarıyor. Bu konuyla ilgili küçük ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
İşin garibi, Büyük kurumsal yapılarda işe konu direkt yönetişim meselesine dönüyor (en azından benim deneyimim böyle). Logosoft’ta geçen yıl yürüttüğümüz Azure ve GitHub entegrasyonlu projede kalite sinyallerini mümkün olduğunca ayrıştırmaya çalışmıştık; çünkü raporlamada tek sepette toplanan veriler yanlış karar üretiyordu — özellikle yönetim toplantılarında bu çok can sıkıyordu. Low Quality gibi etiketler burada işinizi bayağı kolaylaştırır (inanın bana)
| Kategori | Anlamı | Sahadaki etkisi |
|---|---|---|
| Spam | Açıkça istenmeyen içerik | Daha sert aksiyon gerekir |
| Abuse | Saldırgan veya zarar verici içerik | Toksisite yönetimi için kritik |
| Low Quality | Zayıf, alakasız veya faydasız içerik | Daha hassas moderasyon sağlar |
Sahada bu tarz küçük iyileştirmeler neden önem kazanıyor?
Bazen insanlar büyük duyurulara fazla odaklanıyor ve ufak dokunuşları küçümsüyor… sonra ay sonunda operasyon maliyeti patlıyor! Ben bunu defalarca gördüm. Bilhassa açık kaynak topluluklarında problem büyüklüğü tek tek mesajlardan çok toplam gürültüyle ölçülüyor — bu farkı kavrayanlar çok daha rahat çalışıyor.
Açık konuşayım: GitHub’ın bu hamlesi kağıt üstünde devasa görünmüyor. Ama pratikte işe yarar türden biri. E peki, sonuç ne öldü? Çünkü moderatörün karar vermesini hızlandırıyor ve en önemlisi insanlara “bu yorum kötü niyetli olmayabilir ama yine de işe yaramıyor” deme imkânı veriyor.
Metrik tarafını unutmayın
E tabiî burada güzel soru şu: Bu kategori gerçekten kullanılacak mı? Eğer ekipler bunu tutarlı biçimde uygulamazsa veri kirlenir. Anlam kaybolur. 2026’nın mart ayında yaptığım bir değerlendirmede — bir SaaS şirketinin support-to-dev akışında — benzer sorun yaşamıştık; herkes farklı etiket kullandığı için dashboard güzel görünüyordu ama gerçek hikâyeyi hiç anlatmıyordu.
Copilot Code Review metriklerinde de benzer şeyi konuşmuştuk zaten… Metrik varsa disiplin gerekir, yoksa sayı süs olur gider. Bu yüzden yeni kategoriye geçerken kısa bir eğitim notu hazırlamak fena fikir değil: (inanın bana) github ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
- Düşük kaliteyi spam ile karıştırmayın.
- Saldırgan dili abuse olarak işaretleyin.
- Sadece faydasız olanı low quality’e alın.
- Ekip içinde örneklerle ortak tanım oluşturun.
Bence güçlü yanı ne? Zayıf yanı ne?
Güçlü yanı netlik veriyor olması. Karmaşayı azaltıyor. Moderasyonu daha insanı hâle getiriyor. Bir yorumun neden saklandığını açıklamak kolaylaşıyor… ve inan bana, bunu küçümseme — ekip içi sürtüşmelerin önemli bir kısmı tam oradan çıkıyor.
Zayıf yanıysa şu olabilir: kategori fazla geniş kullanılırsa anlamsızlaşır. Mesela her hoşnutsuz yorumu low quality diye işaretlemeye başlarsanız sistem hızla bozulur. Biraz disiplin lazım. Yoksa iyi fikir bile birkaç haftada sıradanlaşır, kimse ciddiye almaz. Microsoft Foundry Mart 2026: Sahadan İlk İzlenimler yazımızda bu konuya da değinmiştik.
Benim beklentim orta vadede bunun özellikle community discussion alanlarında daha belirgin fayda sağlaması yönünde. Pull request tartışmalarında zaten tonlama hassas oluyor. Commit altındaki kısa yorumlarda işe kalite sorunu bazen doğrudan teknik gürültüye dönüşüyor — orada bu filtre bayağı iş görür diye düşünüyorum.
Kendi deneyimimden küçük notlar
Bunu yaşayan biri olarak söyleyeyim, AZ-104 sınavına hazırlanırken log analizi yaparken öğrendiğim şeylerden biri şuydu: veriyi doğru sınıflandırmazsan kök nedeni bulamazsın. Burada da aynısı geçerli. Yanlış etiketlenmiş yüzlerce yorum size güvenlik alarmı kadar gürültülü gelir ve kimse gerçek problemi göremez.
İşte tam da bu noktada devreye giriyor.
Bir arkadaşım geçen sene İstanbul’da açık kaynak odaklı küçük bir ekiple çalıştı; yorumların yüzde 30’una yakınını gereksiz bulmuşlardı. Elimizde düzgün sınıflama olmadığı için kanıtlayamıyorlardı. Low Quality seçeneği tam o gri alanı dolduruyor işte… İlginç, değil mi? çok iddialı değil ama gerekli!
Bunu nasıl kullanmalı?
# Moderasyon karar akışı — basit mantıkif comment.is_spam:
classify("Spam")
elif comment.is_abusive:
classify("Abuse")
elif comment.is_unhelpful_or_low_signal:
classify("Low Quality")
else:
leave_visible()
}
Hani, Böyle düşünmek faydalı oluyor çünkü ekip içi tutarlılık sağlıyor. Aksi hâlde herkes kendi kafasına göre hareket ediyor… ve sonra rapor paneline bakıp “bu rakam neden böyle çıktı?” diye birbirimize bakıyoruz. Şimdi şöyle söyleyeyim — işin komiği şu — kendi adıma konuşayım — ki sorun çoğu zaman araçta değil, kararda oluyor (en azından benim deneyimim böyle). Araç hazır, karar veren insan.
Peki bundan sonra ne beklemeliyiz?
Bence GitHub burada ufak. Önemli bir çizgi çekti: “her rahatsız edici şey kötü niyet değildir.” Bu yaklaşım bana olgunluk göstergesi gibi geliyor. Platformlar büyüdükçe dil de inceliyor, etiketlerin kaba kalması yetmiyor artık…
Şahsen, Eğer sız de kurumsal tarafta GitHub kullanıyorsanız — özellikle internal developer portal, community-driven repository veya vendor collaboration senaryolarında — bu özelliğin operasyonel karşılığını test edin derim. Çünkü bazen küçük görünen bir menü seçeneği, ay sonunda toplantıda kafa ağrısını gerçekten azaltabiliyor (ciddiyim). Cidden!
Sıkça Sorulan Sorular
Low Quality ile Spam arasındaki fark nedir?
Spam genelde istenmeyen ve çoğu zaman kasıtlı içeriktir; Low Quality işe zararlı olmak zorunda değildir ama faydasızdır.
GitHub’ın yeni seçeneği bu gri alanı ayırmak için geldi.
Yanı amaç cezalandırmak değil, doğru sınıflamaktır.
Bütün repolarda kullanılabiliyor mu?
Evet, issue’larda, discussion’larda, pull request’lerde ve commit yorumlarında kullanılabiliyor.
Yorum menüsünden erişiliyor.
Akış oldukça sade tutulmuş.
Küçük ekipler için gerçekten gerekli mi?
Eğer topluluğunuz küçükse şart olmayabilir.Ama büyümeye başladıysanız erken dönemde düzen kurmak avantaj sağlar.
Sonradan temizlik yapmak genelde daha yorucudur.
This feature moderation metrics help mi?
Evet, özellikle hangi tür düşük kaliteli yorumların arttığını görmek açısından yardımcı olur.
Ama ancak ekip içinde tutarlı kullanım varsa anlamlı veri verir.
Kısacası araç var, disiplin de lazım.
Kaynaklar ve İleri Okuma
GitHub Changelog — New Low Quality option in the Hide comment menü
GitHub Docs — Moderating comments and conversations
GitHub’da Güvenlik Sekmesi Değişti: Kalite de Eklendi
Copilot Code Review Metrikleri: Aktif mi Pasif mi?
Bir dakika — bununla bitmedi.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments