GitHub CLI artık takma adlı telemetri topluyor

• GitHub CLI artık takma adlı telemetri gönderiyor; amaç, özellik kullanımına görünürlük sağlamak ve ürünün iyileştirilmesini desteklemek
• Alt komutların benimsenmesi ve flag kullanım kalıpları temel alınarak iş öncelikleri belirleniyor, kullanıcı ihtiyaçlarının karşılanıp karşılanmadığı değerlendiriliyor ve keşfedilebilirlik ile tasarım yeniden gözden geçiriliyor
• Açık kaynak uygulama sayesinde telemetri kodu cli/cli deposunda doğrudan incelenebiliyor; logging mode ile gerçek gönderim öncesinde JSON payload görüntülenebiliyor
• Vazgeçme işlemi GH_TELEMETRY=false, DO_NOT_TRACK=true ortam değişkenleri veya gh config set telemetry disabled ile yapılabiliyor; ortam değişkenleri config ayarından öncelikli uygulanıyor
• Telemetri olayları GitHub’ın dahili analiz altyapısına gönderiliyor; bu sayfa yalnızca gh istemcisinin istemci tarafı veri toplamayı ele alıyor, extensions ve Copilot CLI ise ayrı kapsamda

---

Telemetri

• GitHub CLI, ürünün iyileştirilmesini desteklemek amacıyla takma adlı telemetri gönderiyor
• Kullanıcıların hangi verilerin neden gönderildiğini anlayabilmesi için bilgi sunuluyor

Telemetri neden toplanıyor

• Özellikle agentic adoption artarken, GitHub CLI özellik kullanımına görünürlük ihtiyacından ve ürünün gerçekte nasıl kullanıldığını anlama amacından söz ediliyor
  • Ekip bu verileri iş önceliklerini belirlemek için kullanıyor
  • Özelliklerin gerçekten kullanıcı ihtiyaçlarını karşılayıp karşılamadığı değerlendiriliyor
• Yeni bir alt komut yayınlandıktan sonra benimsenip benimsenmediğini görmek amacı açıkça belirtiliyor
  • Kullanıcı neredeyse yoksa ilgili özelliğin keşfedilebilirliği veya tasarımı yeniden gözden geçirilebiliyor
  • Belirli flag’lerle birlikte yüksek kullanım görülürse daha iyi bir deneyime hangi noktada yatırım yapılacağı anlaşılabiliyor

Telemetriyi inceleme

• GitHub CLI açık kaynak olduğundan, telemetri uygulaması cli/cli deposunda doğrudan incelenebiliyor
• Gerçek gönderim yapmadan hangi verilerin gönderileceğini görmek için logging mode kullanılabiliyor
  • Ortam değişkeni yöntemi destekleniyor
    • export GH_TELEMETRY=log
  • CLI yapılandırma yöntemi destekleniyor
    • gh config set telemetry log
• Logging mode’da normalde gönderilecek JSON payload stderr’e yazdırılıyor
  • Telemetriyi etkin bırakıp bırakmamaya karar vermeden önce her alan incelenebiliyor
  • Örnek komut olarak GH_TELEMETRY=log gh repo list --archived veriliyor
• Örnek payload içinde yer alan olay bilgileri belirtiliyor
  • Olay türü command_invocation
  • Dimensions alanları olarak agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version yer alıyor
  • Örnek değerler olarak architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0 gösteriliyor
• İlgili komut, yalnızca çalıştırılan tam komut ve bağlam için telemetriyi loglayabiliyor
  • Ortam değişkenlerini değiştirirseniz payload içindeki events ve event dimensions değişebiliyor
  • Kimliği doğrulanmış hesap değiştiğinde de dahil edilen alanlar farklı olabiliyor

Vazgeçme yöntemi

• Logging mode’da görülen telemetri için vazgeçme seçeneği bulunuyor
• Ortam değişkeni yöntemi destekleniyor
  • export GH_TELEMETRY=false
  • Falsy değer olarak 0, false, disabled, boş string kullanılabiliyor
  • DO_NOT_TRACK geleneği de destekleniyor ve export DO_NOT_TRACK=true örneği veriliyor
• CLI yapılandırma yöntemi destekleniyor
  • gh config set telemetry disabled
• Ortam değişkenleri, config değerlerinden daha yüksek önceliğe sahip

Veriler nereye gönderiliyor

• Telemetri olayları GitHub’ın dahili analiz altyapısına gönderiliyor
• Verilerin nasıl işlendiğine dair ek bilgi için GitHub General Privacy Statement yönlendirmesi yapılıyor

Ek bilgiler

• GitHub CLI, GitHub ve üçüncü taraf extensions yüklenerek işlevlerin genişletilmesini destekliyor; buna agents da dahil
• Bu extensions kendi kullanım verilerini toplayabiliyor olabilir
  • Bunlar vazgeçme ayarlarıyla kontrol edilmiyor
  • Telemetriyi nasıl raporladıklarını ve devre dışı bırakmanın mümkün olup olmadığını öğrenmek için her extension’ın belgelerine bakmak gerekiyor
• Bu sayfa yalnızca GitHub CLI gh için istemci tarafı veri toplamayı ele alıyor
  • GitHub Copilot ve Copilot CLI için geçerli değil
  • Copilot CLI verileri ayrı şekilde topluyor
  • İlgili bilgi konumları olarak Using GitHub Copilot CLI, Responsible Use of the GitHub Copilot CLI belirtiliyor

[GN⁺]

Hacker News görüşleri

• Şirketlerdeki geliştirici ekiplerinin neden sürekli telemetri ile kullanıcıları gözlemlemek istediğini merak ediyorum
  İyi mühendislik ve tasarım tek başına yeterli değil mi diye sormak geliyor içimden
  Git, kimin hangi özellik ve komutu kullandığına dair ayrıntılı analizler olmadan 20 yıldan uzun süredir gayet iyi çalıştı; telemetri olsaydı gerçekten daha mı iyi olurdu, yoksa sadece dikkat dağıtan veri mi artardı, emin değilim

  • Eskiden ben de gereksiz olduğunu düşünürdüm ama kendi startup’ımı kurduktan sonra fikrim değişti
    analytics olmadan araba kullanmak ama gözlerin bağlı olması gibi hissettiriyor
    Kullanıcıların gerçekten neyi önemsediğini, hangi akışları optimize etmek gerektiğini bilemiyorsun ve insanların söyledikleriyle yazılımı gerçekte kullanma biçimleri arasındaki fark şaşırtıcı derecede büyük
  • Geliştiricilerle kullanıcıların ihtiyaçları ve düşünceleri farklı olduğu için, iyi tasarımın tek başına yeterli olmadığını düşünüyorum
    İnsanlardan iyi geri bildirim almak çoğu zaman zor oluyor; herkes özellik X fikrini sevdiğini söylese bile pratikte hiç kullanmayabiliyor
    Ayrıca sesi çok çıkan bir hayran kitlesi varmış gibi görünse de bu gelir ya da gerçek kullanım olarak geri dönmeyebilir
    Git’te telemetri olsaydı daha iyi olma ihtimalinin yüksek olduğunu düşünüyorum
    Git’in arayüzü meşhur derecede kötü
    İnsanların başlangıçta ne kadar çok zorlandığı verilerde hemen ortaya çıkardı ve örneğin git checkout -- foo.txt gibi sezgisel olmayan komutlar yerine git restore gibi iyileştirmeler çok daha erken gelebilirdi
  • Ne yazık ki bunun sebebinin teknik olmayan karar vericilerin çokluğu olduğunu düşünüyorum
    Aracı bizzat kullanmayan insanlar gerçek kullanım biçimini anlamadığı için, geliştirici araçlarından sorumlu PM kendi işini yapabilmek adına bu tür verileri talep ediyor
    Bu, e-ticaret PM’inin frontend’e bir sürü izleme script’i yüklemesine benziyor
    Eskiden mühendisler tek başına da kullanıcı etkileşimini yeterince tasarlayabiliyordu; ama VC döneminden sonra teknik ürünlerin derinlemesine teknik olmayan kişilerce yönlendirildiği bir paradigma yerleşti ve bence sorun da bu
    Sonunda veri onların eline geçiyor ve biri de PM maaşını haklı çıkarmış oluyor gibi görünüyor
  • Git’te telemetri olsaydı işe yaramazdı diye bunu çok net söyleyebileceğimizi sanmıyorum
    Bu bana apaçık gelmiyor
  • Git’in tasarımı ve kullanılabilirliği berbat bence
    Mühendislerin mühendisler için arayüz yaptığı ve iyi bir geri bildirim döngüsünün olmadığı tipik bir örnek gibi duruyor
    İronik olan şu ki bu örneğin kendisi bile, geliştiricilerin kendi ürünlerinin gerçekte nasıl kullanıldığını daha iyi anlaması gerektiğini gösteriyor
    Geliştiricinin kafasındaki kullanım senaryosu çoğu zaman gerçeklikten oldukça farklı oluyor

• gh CLI’deki opt-out meselesinin düşünüldüğünden daha karmaşık olduğunu düşünüyorum
  gh, CI/CD pipeline’larında ve sunucu ortamlarında da çalışıyor; o ortamlarda insanlar gizlilik yüzünden değil, ağ kısıtları yüzünden github.coma giden bağlantıların hiç olmasını istemeyebilir
  Böyle yerlerde telemetri varsayılan olarak açıksa CI başarısız olabilir ya da bir Bastion host GitHub’a hiç erişemeyebilir
  Buna karşılık Git’in kendisi, kullanıcı açıkça push edene kadar tamamen yerelde çalışır
  Yani güven modeli farklı
  Git, yapılandırılmadıkça asla phone home yapmaz; ama ghnin GitHub API’si etrafında bir sarmalayıcı olması nedeniyle işlevsel olarak çağrılar yapmasının gerektiğini kabul ediyorum
  Yine de bu durumdan bağımsız olarak, komut kullanım kalıplarını ayrıca toplayıp yüklemek gerekip gerekmediği ayrı bir tartışma olmalı

  • Telemetri gönderilemedi diye programın hard error verip çökeceğini sanmıyorum
  • gh, GitHub.coma bağlanamıyorsa fiilen işe yaramaz mı diye merak ediyorum
    Yoksa asıl kullanım senaryosu enterprise GitHub bağlantıları mı?

• Eğer üç geliştirici zamanlarının yüzde 80’ini kod tabanının belli bir alanına harcıyor ama orada neredeyse hiç kullanım yoksa ve bunun gerçekçi biçimde artma ihtimali de görünmüyorsa, o insan gücünü başka yere kaydırmak ya da özelliğin kendisini yeniden düşünmek daha mantıklı olabilir
  Ama bu tür analytics sistemlerinin sorunu şu: masum biçimde kullanılabilirler, fakat benzersiz tanımlayıcıları davranış kalıplarıyla bağlayıp makine öğrenmesiyle kimliği yeniden kurmak da mümkün
  Buna zaman damgaları da eklenirse durum daha da kötüleşir
  Bu yüzden hangi telemetrinin ne zaman gönderildiğinin tam olarak görünür olmasını isterdim
  Mesela veriyi gerçekten göndermeden, verbose modda neyin gönderileceğini gösteren bir seçenek olabilir; kullanıcı da bunu inceleyip ardından açıp açmamaya karar verir
  Steam Hardware Survey’nin ne gönderildiğini gösteren yaklaşımı bana daha doğru geliyor

• Tüm gh komutları sonuçta sadece GitHub API sarmalayıcıları; bence bu tartışmayı daha da bulanıklaştıran da bu

• Böyle kısa PR’ları seviyorum
  https://github.com/cli/cli/pull/13254
  İçerik de basit; telemetriyi engelleyen env var kaldırılıyor ve bu da varsayılan olarak etkin hale getirildiği anlamına geliyor diye okuyorum

  • Sadece varsayılan olarak etkin değil, sanki tamamen devre dışı bırakılamaz gibi de görünüyor
    Enterprise hariç pratikte zorunlu açıkmış gibi bir yapı var

• Geçen ay homelab’ime gitea kurmuş olmaktan gerçekten memnunum
  GitHub’dan içe aktarma özelliği de var ve açıkçası GitHub’dan daha hızlı, uptime’ı da daha iyi gibi geliyor
  Claude da tea CLI ve Git ile gayet iyi çalışıyor; neredeyse GitHub’ın bir kopyası gibi ama şu ana kadar bence daha bile iyi

  • Ben Forgejo kullanıyorum; aynı çekirdek kodu paylaştıkları için olsa gerek gerçekten harika
    Hızlı ve uptime’ı iyi
    Hatta masamın yanındaki dolapta duran bir Pi 4 üzerinde çalışıyor, internet kesilse bile hizmet vermeye devam ediyor
    Yedekleri borg ve syncthing ile site dışına da gönderiyorum
    Kurulum biraz uğraştırıyor ama sonrasında bakım süresi neredeyse sıfıra yakın
    İki haftada bir kadar SSH ile girip SSD alanını, RAM kullanımını, apt update, upgrade ve büyük sürüm yükseltmelerini kontrol etmem yetiyor

• GitHub’ın zaten kendi sunucularına gelen tüm istekleri topladığını ve toplulaştırdığını herkes varsaymıyor mu diye merak ediyorum
  Sonuçta gh CLI’nin varlık nedeni de o sunucularla etkileşim kurmak
  İsteklerin izlenmesini gerçekten istemiyorsan, sadece bu ayardan çok daha fazlasını opt-out etmen gerekir diye düşünüyorum

  • Sunucuda veri olduğu için elbette zaten baktıklarını düşünüyorum
    Ama bu sefer istemci tarafı metriklerini de ekleyerek, yalnızca GitHub’a gidenleri değil GitLab, Codeberg gibi başka yerlere giden akışları da daha iyi izlemek istiyorlar gibi görünüyor

• GitHub açısından iyi bir şey olabilir bence
  Her şirketin bu tür verilere ihtiyacı var; bazıları bunu ürünü iyileştirmek için kullanır, bazılarıysa daha az takdire şayan amaçlarla
  HN kullanıcılarının telemetriden hoşlanmadığını biliyorum ama kendi SaaS’ını yaptıysan telemetrynin fiilen vazgeçilmez olduğunu fark ediyorsun

  • GitHub CLI bir SaaS değil, komut satırı yardımcı programı
  • Bence önce doğrudan kullanıcıya sormak gerekmez mi?
    Sonuçta burada eksik olan şey diyalog
  • Bir aracın telemetri içeriğini doğrulamanın en iyi uygulaması ne olur diye merak ediyorum
    Asıl mesele ayrıntılarda gizli ve kullanıcıyla ürünü yapan taraf arasında, iki tarafın da makul bulacağı bir orta zemin oluşturacak güvenilir bir aracı hizmet olup olamayacağını düşünüyorum
    Claude’un yardımıyla araştırdıklarımı bir Gist’te derliyorum
  • Yapay zeka savunucularının konuşma tarzı hep birbirine benziyor gibi geliyor

• Microsoft’un Embrace, extend, extinguish yaklaşımını hatırlatıyor
  İlk iki aşama zaten oldu ve bence 5 yıl içinde GH CLI, GitHub depolarıyla etkileşim kurmanın tek yolu haline gelecek
  O zaman üçüncü aşama da tamamlanmış olur ve döngü kapanır

  • Bu tahmine seve seve iddiaya girerim
    Ne kadarına gireceğiz diye soracak kadar gerçek dışı bir öngörü gibi geliyor
  • Bu tür iddialar gerçekten insanı yoruyor
    İnsanlar WSL, GPU desteği, WSLg ve PowerShell için de sürekli EEE çerçevesini kullandı ama pratikte böyle bir şey yaşanmadı
    Şimdi de durum aynı ve hatta baştan planlanmış olduğuna dair pek iz de görünmüyor
    İçgüdüyle yorumlanacak bir şey değil bu; 90’larda Microsoft’un gerçekten kullandığı tekrar eden yöntemin bugün tam olarak nerede yeniden üretildiğine dair kanıt görmek istiyorum
    Microsoft Git’in açık kaynaktan daha fazla özellikle kilitleme yaptığına dair bir durum yok; Microsoft Linux için de aynısı geçerli
    GitHub, Git üzerinde bir sarmalayıcı ve HTTP ile SSH üzerinde çalışan bir Git sunucusu olma gibi temel bir tasarıma sahip
    Bu temeli bozup depo erişimini sadece gh ile kilitlemek çok büyük bir değişiklik olur; bence pek gerçekçi değil
    gh sadece API çağrılarını kolaylaştıran bir araç ve GitHub kullanıcılarının büyük kısmı varlığından bile haberdar değil
    GitHub’ı asıl çökertme ihtimali olan şey kötü niyetli bir EEE değil, beceriksiz yönetim olabilir
    Kullanıcıyı ve ürünü anlamayan yöneticiler yüzünden çökme ihtimali daha yüksek gibi geliyor
  • Ben o tahmine tamamen şüpheyle yaklaşmıyorum
    Şimdiden bazı depolar gh olmadan uğraştırıcı gelmeye başladı ve yavaş yavaş zorunlu akışlar ortaya çıkıyor gibi
    gh tam olarak ne gibi ek faydalar sağlıyor bilmiyorum çünkü kullanmadım ama bana standart Git komutları yetiyor

• Buradaki pseudonymous telemetry ifadesinin kimliği doğrudan belli etmeyen telemetri anlamına mı geldiği, yoksa aslında anonim olmayan telemetri demek mi olduğu kafamı karıştırıyor
  Bu iki ifade neredeyse zıt anlama geliyor; mevcut ifadeyle okununca tanımlanabilir veri topladıklarını söylüyor gibiler

  • İlgili sayfada sadece pseudonymous ifadesi var; pseudoanonymous ise HN gönderisini yazanın uydurduğu bir ifade gibi görünüyor
  • Bunun anlamını, bir kişinin kimliğiyle ya da GitHub hesabıyla ilişkilendirilmiyor ama aynı makineden gelen tüm telemetrinin birlikte görülebilmesi olarak anlıyorum
    Her makineye bir UUID veriliyor ve makineyi bunun üzerinden tanımlıyor gibiler