GitHub amplió las opciones para organizar la clasificación de Issues con dos cambios que llegaron a disponibilidad general el 25 de septiembre de 2026: vistas guardadas privadas en las páginas de Issues de los repositorios y un soporte más amplio para la relación Relates to. En la práctica, el primer cambio permite mantener colas y filtros personales sin convertir cada recorte de trabajo en una vista compartida por todo el repositorio. El segundo ofrece una relación explícita para conectar issues relacionadas sin afirmar que una bloquea, duplica, contiene o cierra a la otra.
Qué cambia en las vistas guardadas de Issues
Las páginas de Issues de los repositorios ya venían incorporando vistas guardadas. En junio de 2026, GitHub puso la función en vista previa pública con énfasis en vistas compartidas, como bugs sin responsable, elementos que necesitan clasificación o solicitudes reportadas por clientes. El 25 de septiembre, GitHub anunció la disponibilidad general de vistas guardadas privadas, orientadas a recortes personalizados que no necesitan convertirse en una convención para todo el equipo.
Esta diferencia es útil porque la clasificación suele mezclar dos necesidades. La primera es colectiva: el equipo necesita colas estables y reconocibles, por ejemplo, “Needs triage” o “Unassigned bugs”. La segunda es individual: cada persona puede necesitar seguir un subconjunto temporal, como issues de un componente, elementos que piensa revisar durante su turno o tickets vinculados a una investigación específica. Una vista privada mantiene ese segundo tipo de organización como algo personal, sin sobrecargar la navegación compartida.
Cómo usar vistas privadas sin fragmentar la clasificación
La ventaja no consiste en convertir cada búsqueda en una vista nueva. Un enfoque más consistente es reservar las vistas compartidas para colas que representen el proceso oficial del repositorio y usar las privadas para preferencias o rutinas de trabajo de una persona.
- Vista compartida: representa un estado operativo que otras personas necesitan encontrar e interpretar de la misma manera.
- Vista privada: representa una forma personal de recortar la misma base de issues sin crear una nueva regla para el equipo.
- Búsqueda temporal: sigue siendo adecuada cuando el filtro es puntual y no vale la pena guardarlo.
Este criterio reduce dos problemas habituales: demasiadas vistas casi iguales y dependencia de filtros personales para procesos que deberían ser visibles para el equipo. Una cola crítica de clasificación, por ejemplo, no debería existir solo como vista privada de la persona que normalmente hace la primera revisión.
Qué significa la relación Relates to
La relación Relates to entró en vista previa pública en agosto de 2026 para conectar dos issues sin asignarles una relación causal o jerárquica. Es distinta de relaciones como bloqueo, duplicidad o sub-issues. Su objetivo es registrar que dos elementos comparten contexto incluso cuando ninguno depende del otro.
El 25 de septiembre, GitHub informó que esta relación pasó a funcionar de forma más amplia en REST API, GraphQL API, webhooks, eventos de timeline, búsqueda de issues y búsqueda de Projects. Esto importa para equipos que no gestionan relaciones entre tickets solamente desde la interfaz web, sino también mediante automatizaciones, integraciones y consultas.
Dónde ayuda Relates to durante la clasificación
Durante la clasificación, “Relates to” resulta útil cuando conviene examinar dos issues en conjunto pero todavía no hay evidencia suficiente para clasificarlas como duplicadas o dependientes. Algunos ejemplos son reportes diferentes que apuntan al mismo componente, un bug y una solicitud de mejora que comparten contexto, o tickets de repositorios distintos conectados con el mismo incidente o iniciativa.
La precaución es no usar “Relates to” como sustituto genérico para cualquier conexión. Cuando existe una relación más precisa, como bloqueo o duplicidad, la relación específica sigue comunicando mejor el estado del trabajo. “Relates to” funciona mejor para asociación contextual, especialmente cuando el equipo quiere conservar ambos elementos y hacer explícita la navegación entre ellos.
Cómo reorganizar un flujo de clasificación con las dos novedades
- Mantén pocas vistas compartidas y con una función clara. Deben reflejar colas reales del proceso, no preferencias individuales.
- Crea vistas privadas para recortes personales recurrentes. Pueden incluir labels, responsables, tipos de issue u otros filtros que una persona use con frecuencia.
- Usa Relates to cuando la asociación sea contextual. Si la relación es bloqueo, duplicidad o jerarquía, prefiere la relación específica.
- Revisa automatizaciones que interpretan relaciones entre issues. Como “Relates to” ahora aparece en APIs, webhooks, timeline y búsquedas, las integraciones pueden observar o procesar esta relación cuando sea relevante para el flujo.
- Evita que una organización personal se convierta en dependencia operativa. Si una cola privada pasa a ser necesaria para otras personas, debe trasladarse a un mecanismo compartido adecuado.
Qué revisar en automatizaciones e integraciones
Para equipos que usan scripts, GitHub Apps o sincronizaciones externas, la disponibilidad de “Relates to” en diferentes superficies merece una revisión dirigida. La pregunta principal es si alguna automatización supone que las relaciones entre issues son solamente de bloqueo, dependencia o jerarquía. Si es así, puede ser necesario distinguir el nuevo tipo de relación en lugar de tratarlo como equivalente a los demás.
También conviene revisar búsquedas e informes que intentan reconstruir relaciones a partir de texto, labels o referencias manuales. Cuando la conexión semántica entre dos issues pueda representarse directamente con “Relates to”, la automatización puede depender menos de convenciones informales. Esto no significa sustituir labels, tipos o campos, sino usar cada mecanismo para la información que expresa mejor.
Resumen práctico
Las vistas privadas ayudan a separar la organización personal de las colas oficiales de clasificación. La relación “Relates to” registra una asociación entre issues sin declarar bloqueo, duplicidad o jerarquía y ahora puede consumirse en más superficies de la plataforma. En conjunto, ambos cambios permiten mantener la clasificación compartida más simple y conservar contexto estructurado entre tickets.
Fuentes y referencias
- GitHub Changelog: Private saved views for repository issues and “Relates to” issue relationship is generally available
- GitHub Changelog: “Relates to” issue relationship in public preview and multi-select fields is generally available
- GitHub Changelog: Saved views for repository issues, public preview
- GitHub Changelog: Pinning saved views to the repository issues sidebar is generally available and more
