GitHub CLI ahora recopila telemetría seudónima

• GitHub CLI envía telemetría seudónima con el objetivo de obtener visibilidad sobre el uso de funciones y apoyar la mejora del producto
• Se utiliza la adopción de subcomandos y los patrones de uso de flags para definir prioridades de trabajo, evaluar si se satisfacen las necesidades de los usuarios y reconsiderar la discoverability y el diseño
• Con una implementación de código abierto, se puede revisar directamente el código de telemetría en el repositorio cli/cli, y con el modo logging es posible ver el payload JSON antes de que se envíe realmente
• Es posible hacer opt-out con la variable de entorno GH_TELEMETRY=false, DO_NOT_TRACK=true o gh config set telemetry disabled, y las variables de entorno tienen prioridad sobre la configuración
• Los eventos de telemetría se envían a la infraestructura interna de análisis de GitHub, y esta página solo cubre la recopilación de datos del lado del cliente de gh; las extensiones y Copilot CLI se tratan por separado

---

Telemetría

• GitHub CLI envía telemetría seudónima con el objetivo de apoyar la mejora del producto
• Se ofrece información para que los usuarios entiendan qué datos se envían y por qué

Por qué se recopila telemetría

• Se menciona la necesidad de obtener visibilidad sobre el uso de las funciones de GitHub CLI, especialmente a medida que crece la adopción de agentes, con el fin de entender cómo se usa realmente
  • El equipo usa estos datos para definir prioridades de trabajo
  • Evaluar si las funciones realmente satisfacen las necesidades de los usuarios
• También se indica el objetivo de confirmar la adopción tras el lanzamiento de nuevos subcomandos
  • Si casi nadie los usa, puede ser necesario reconsiderar la discoverability o el diseño de esa función
  • Si se detecta un uso alto junto con ciertos flags, se puede identificar mejor dónde invertir para ofrecer una mejor experiencia

Revisión de la telemetría

• GitHub CLI es código abierto, y la implementación de la telemetría se puede revisar directamente en el repositorio cli/cli
• Para comprobar qué datos se enviarán sin transmitir nada realmente, se puede usar el modo logging
  • Compatible con variables de entorno
    • export GH_TELEMETRY=log
  • Compatible con configuración del CLI
    • gh config set telemetry log
• En el modo logging, el payload JSON que normalmente se enviaría se imprime en stderr
  • Esto permite revisar cada campo antes de decidir si se mantiene activada la telemetría
  • Se muestra como comando de ejemplo GH_TELEMETRY=log gh repo list --archived
• Se especifica la información del evento incluida en el payload de ejemplo
  • Tipo de evento command_invocation
  • En dimensions se incluyen agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
  • Como valores de ejemplo se muestran architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0
• Ese comando solo puede registrar telemetría sobre el comando exacto y el contexto en que fue ejecutado
  • Si se cambia la variable de entorno, pueden cambiar los events y event dimensions incluidos en el payload
  • También pueden variar los elementos incluidos si cambia la cuenta autenticada

Cómo hacer opt-out

• Es posible hacer opt-out de la telemetría revisada en el modo logging
• Compatible con variables de entorno
  • export GH_TELEMETRY=false
  • Se pueden usar valores falsy como 0, false, disabled, cadena vacía
  • También se admite la convención DO_NOT_TRACK, con el ejemplo export DO_NOT_TRACK=true
• Compatible con configuración del CLI
  • gh config set telemetry disabled
• Las variables de entorno tienen mayor prioridad que el valor de configuración

A dónde se envían los datos

• Los eventos de telemetría se envían a la infraestructura interna de análisis de GitHub
• Para más información sobre cómo se procesan los datos, se indica consultar la GitHub General Privacy Statement

Información adicional

• GitHub CLI permite ampliar funciones mediante la instalación de extensiones de GitHub y de terceros, incluidos agentes
• Estas extensiones pueden recopilar sus propios datos de uso
  • No están controladas por la configuración de opt-out
  • Es necesario revisar la documentación de cada extensión para confirmar cómo reporta telemetría y si puede desactivarse
• Esta página solo trata la recopilación de datos del lado del cliente del gh de GitHub CLI
  • No se aplica a GitHub Copilot ni a Copilot CLI
  • Copilot CLI maneja la recopilación de datos por separado
  • Se indican como referencias Using GitHub Copilot CLI y Responsible Use of the GitHub Copilot CLI

[GN⁺]

Comentarios de Hacker News

• Me pregunto por qué los equipos de desarrollo corporativos siempre quieren observar a los usuarios con telemetría
  Quisiera preguntar si no basta con buena ingeniería y buen diseño
  Git ha funcionado bien por más de 20 años sin análisis detallados de quién usa qué funciones y comandos, y me pregunto si realmente habría mejorado con telemetría o si solo habría aumentado la información que distrae

  • Antes yo también pensaba que era innecesario, pero después de crear una startup cambié de idea
    Sin analytics es como manejar con los ojos vendados
    No puedes saber qué valoran de verdad los usuarios, qué flujos debes optimizar, y es sorprendentemente grande la diferencia entre lo que la gente dice y cómo realmente usa el software
  • Como los desarrolladores y los usuarios tienen necesidades e ideas distintas, creo que el buen diseño por sí solo no basta
    Muchas veces también es difícil obtener buen feedback de la gente, y aunque a todos les parezca buena la idea de la función X, en la práctica puede que no la usen para nada
    Además, aunque parezca que hay una base de fans muy ruidosa, eso puede no traducirse en ingresos ni en uso real
    Creo que Git probablemente habría mejorado si hubiera tenido telemetría
    Git es famoso por tener una UI mala
    Los datos habrían mostrado de inmediato cuánto se perdía la gente al principio y, por ejemplo, mejoras como git restore habrían llegado mucho antes en lugar de comandos poco intuitivos como git checkout -- foo.txt
  • Lamentablemente, creo que este fenómeno existe porque hay muchos tomadores de decisiones no técnicos
    Como la gente que no usa directamente las herramientas no entiende cómo se usan realmente, el PM a cargo de herramientas de desarrollo termina pidiendo este tipo de datos para poder hacer su trabajo
    Me parece una estructura parecida a la de un PM de comercio electrónico que llena el frontend de scripts de rastreo
    Los ingenieros por sí solos podían diseñar bien la interacción con los usuarios, pero siento que después del VC se consolidó un paradigma donde productos técnicos son dirigidos profundamente por personas no técnicas
    Al final, los datos terminan en sus manos y alguien logra justificar el sueldo del PM
  • Siento que no se puede afirmar con tanta seguridad que la telemetría no le habría servido a Git
    Para mí eso no está claro
  • Creo que Git tiene un diseño y una usabilidad pésimos
    Parece un caso representativo de ingenieros creando interfaces para ingenieros, sin un buen ciclo de retroalimentación
    Irónicamente, este mismo ejemplo muestra que los desarrolladores necesitan entender mejor cómo se usa realmente su producto
    El escenario de uso que el desarrollador tiene en la cabeza suele ser bastante distinto de la realidad

• Creo que el tema del opt-out en gh CLI es más complejo de lo que parece
  gh también corre en pipelines de CI/CD o en entornos de servidor, y en esos entornos puede que no quieran conexiones salientes a github.com no por privacidad, sino por restricciones de red
  En esos casos, si la telemetría viene activada por defecto, el CI podría fallar o un Bastion host podría no poder llegar en absoluto a GitHub
  En cambio, Git en sí funciona completamente en local hasta que el usuario hace push explícitamente
  Es un modelo de confianza distinto
  Git nunca hace phone home si no lo configuras, mientras que gh sí es un wrapper del API de GitHub y reconozco que funcionalmente necesita hacer llamadas
  Aun así, aparte de ese hecho, creo que hay que discutir por separado si también debe recopilar y subir patrones de uso de comandos

  • No creo que el programa vaya a morir con un error duro solo porque no pudo enviar telemetría
  • Me pregunto si gh es prácticamente inútil si no puede conectarse a GitHub.com
    O si el caso principal es conectarse a GitHub Enterprise

• Si tres desarrolladores están gastando el 80% de su tiempo en alguna parte del codebase que en realidad no tiene uso, y tampoco parece realista que vaya a crecer en el futuro, puede ser mejor reasignar esa gente o replantear la función por completo
  Pero el problema de este tipo de analytics es que existe sobre el entendimiento de que se puede reconstruir una identidad con aprendizaje automático al vincular identificadores únicos y patrones de comportamiento
  Si además incluyes marcas de tiempo, es todavía más serio
  Por eso creo que sería bueno mostrar exactamente qué telemetría se envía y cuándo
  Por ejemplo, podría haber una opción para mostrar en modo verbose qué se enviaría, sin enviarlo realmente, y luego dejar que el usuario lo revise y decida si activarlo
  Me parece correcto el enfoque de Steam Hardware Survey, que muestra qué se envía

• Siento que toda esta discusión se vuelve todavía más confusa porque todos los comandos de gh al final no son más que wrappers del API de GitHub

• Me gustan los PR tan cortos como este
  https://github.com/cli/cli/pull/13254
  El contenido también es simple, así que lo interpreto como que quitaron la env var que bloqueaba la telemetría y ahora la cambiaron a activada por defecto

  • Siento que no solo está activada por defecto, sino que además parece imposible desactivarla
    Salvo en enterprise, parece una estructura prácticamente forzada

• Estoy muy satisfecho de haber desplegado gitea en mi homelab el mes pasado
  También tiene función para importar desde GitHub y, honestamente, siento que es más rápido que GitHub y tiene mejor uptime
  Claude también se conecta bien con tea CLI y Git, y aunque es casi una copia de GitHub, hasta ahora incluso me parece mejor

  • Yo uso Forgejo, y como comparte el mismo código base principal, me parece realmente excelente
    Va rápido y tiene buen uptime
    Incluso corre en una Pi 4 en el gabinete al lado de mi escritorio, así que sigue funcionando aunque se caiga internet
    Estoy enviando backups fuera del sitio con borg y syncthing
    La configuración requiere algo de trabajo, pero después de eso el tiempo de mantenimiento es casi cero
    Más o menos cada dos semanas solo entro por SSH para revisar espacio en SSD, uso de RAM, apt update, upgrade y actualizaciones de versión mayor

• Me pregunto si la gente no asume ya que GitHub recopila y agrega todas las solicitudes que llegan a sus propios servidores
  Después de todo, la razón de existir de gh CLI es interactuar con esos servidores
  Si de verdad no quieres rastreo de solicitudes, creo que tendrías que hacer opt-out de muchas más cosas que de esta sola configuración

  • Como los datos están en el servidor, creo que por supuesto ya los están mirando
    Pero esta vez parece que quieren sumar métricas del lado del cliente para rastrear mejor flujos que van no solo a GitHub, sino también a otros lugares como GitLab, Codeberg

• Desde la perspectiva de GitHub, creo que puede ser algo bueno
  Todas las empresas necesitan este tipo de datos, y algunas los usan para mejorar el producto y otras para fines menos nobles
  Sé que a los usuarios de HN no les gusta la telemetría, pero si alguna vez hiciste SaaS, sientes que la telemetry es básicamente esencial

  • Creo que GitHub CLI no es SaaS, sino una utilidad de línea de comandos
  • Más bien, ¿no debería primero preguntársele directamente al usuario?
    Al final, lo que quiero señalar es la falta de conversación
  • Me pregunto cuál es la mejor práctica para verificar el contenido de la telemetría de una herramienta
    La clave está en los detalles, y estoy pensando si existirá algún servicio intermediario confiable que ayude a crear un punto medio aceptable para ambos lados, usuarios y creadores del producto
    Menciona que está organizando en un Gist lo que investigó con ayuda de Claude
  • Siento que todos los defensores de la IA hablan con el mismo tono

• Me hace pensar en Embrace, extend, extinguish de Microsoft
  Los dos primeros pasos ya ocurrieron y predigo que, dentro de 5 años, GH CLI será la única forma de interactuar con repositorios de GitHub
  Entonces se completará también la tercera etapa y el ciclo se cerrará

  • Apostaría con gusto contra esa predicción
    Se siente como una perspectiva irrealista, al punto de querer preguntar cuánto quiere apostar
  • Este tipo de afirmaciones realmente me agotan
    La gente siguió aplicando el marco de EEE a WSL, soporte de GPU, WSLg y PowerShell, pero en realidad eso no pasó
    Tampoco ahora, y desde el principio casi no se ve ni rastro de un plan así
    No es algo que deba interpretarse por intuición; mi postura es que muestren evidencia de dónde se está reproduciendo hoy ese método repetible que Microsoft sí usó en los 90
    No existe ningún Microsoft Git que esté bloqueando con más funciones que el open source, y con Microsoft Linux pasa lo mismo
    GitHub es un wrapper sobre Git y tiene como diseño central ser un servidor Git que corre sobre HTTP y SSH
    Romper esa base y bloquear el acceso a repositorios para que solo se haga con gh sería un cambio demasiado grande, así que no lo veo realista
    gh es solo una herramienta para facilitar llamadas al API, y siento que la mayoría de los usuarios de GitHub ni siquiera sabe que existe
    Más bien, creo que lo que tiene más probabilidades de arruinar GitHub no es un EEE malicioso, sino una gestión incompetente
    Siento que es más probable que caiga por ejecutivos que no entienden a los usuarios ni al producto
  • No desconfío por completo de esa predicción
    Ya siento que algunos repositorios son incómodos de manejar sin gh, y que poco a poco se están creando flujos forzados
    No sé exactamente qué más ofrece gh porque no lo he usado, pero para mí los comandos estándar de Git son suficientes

• Aquí me confunde si pseudonymous telemetry significa telemetría seudónima o si en realidad quiere decir telemetría que no es anónima
  Las dos expresiones significan casi lo contrario, y tal como está redactado ahora, parece que estuvieran diciendo que recopilan datos identificables

  • En esa página solo aparece la expresión pseudonymous, y pseudoanonymous parece ser una invención del autor del post en HN
  • Entiendo que significa que no se vincula con la identidad de la persona ni con la cuenta de GitHub, pero sí permite ver junta toda la telemetría que sale de una misma máquina
    Parece una estructura donde cada máquina tiene un UUID y se la identifica con base en eso