O GitHub ampliou as opções de organização da triagem em Issues com duas mudanças que chegaram à disponibilidade geral em 25 de setembro de 2026: visualizações salvas privadas nas páginas de issues de repositórios e suporte mais amplo ao vínculo Relates to. Na prática, a primeira novidade permite manter filas e filtros pessoais sem transformar cada recorte de trabalho em uma visão compartilhada pelo repositório. A segunda dá um relacionamento explícito para conectar issues correlatas sem dizer que uma bloqueia, duplica, contém ou encerra a outra.
O que muda nas visualizações salvas de Issues
As páginas de Issues de repositórios já vinham recebendo visualizações salvas. Em junho de 2026, o GitHub colocou o recurso em prévia pública com foco em visões compartilhadas, como filas de bugs sem responsável, itens que precisam de triagem ou solicitações reportadas por clientes. Em 25 de setembro, o GitHub anunciou a disponibilidade geral de visualizações salvas privadas, voltadas a recortes personalizados que não precisam virar convenção de toda a equipe.
Essa distinção é útil porque triagem costuma misturar duas necessidades diferentes. A primeira é coletiva: a equipe precisa de filas estáveis e reconhecíveis, por exemplo, “Needs triage” ou “Bugs sem responsável”. A segunda é individual: cada pessoa pode precisar acompanhar um subconjunto temporário, como issues de um componente, itens que pretende revisar naquele turno ou tickets ligados a uma investigação específica. Com uma visão privada, esse segundo tipo de organização pode ficar pessoal, sem poluir a navegação compartilhada.
Como usar visualizações privadas sem fragmentar a triagem
O ganho não está em transformar toda busca em uma nova visualização. O uso mais consistente é reservar as visões compartilhadas para filas que representam o processo oficial do repositório e usar as privadas para preferências ou rotinas de trabalho de uma pessoa.
- Visão compartilhada: representa um estado operacional que outras pessoas precisam encontrar e interpretar da mesma forma.
- Visão privada: representa uma forma pessoal de recortar a mesma base de issues, sem criar uma nova regra para a equipe.
- Busca temporária: continua adequada quando o filtro é pontual e não vale a pena salvá-lo.
Esse critério reduz dois problemas comuns: excesso de visualizações quase iguais e dependência de filtros pessoais para processos que deveriam ser visíveis à equipe. Uma fila crítica de triagem, por exemplo, não deve existir apenas como visão privada de quem costuma fazer a primeira revisão.
O que significa o vínculo Relates to
O vínculo Relates to apareceu em prévia pública em agosto de 2026 para conectar duas issues sem atribuir uma relação causal ou hierárquica. Ele é diferente de relações como bloqueio, duplicidade ou sub-issue. O objetivo é registrar que dois itens têm contexto em comum, mesmo quando nenhum deles depende do outro.
Em 25 de setembro, o GitHub informou que essa relação passou a funcionar de forma mais ampla em REST API, GraphQL API, webhooks, eventos de timeline, busca de issues e busca de Projects. Isso é relevante para equipes que não tratam relações entre tickets apenas pela interface, mas também por automações, integrações e consultas.
Onde Relates to ajuda na triagem
Durante a triagem, “Relates to” é útil quando duas issues precisam ser examinadas em conjunto, mas ainda não há evidência para classificá-las como duplicadas ou dependentes. Exemplos típicos incluem relatos diferentes que apontam para o mesmo componente, um bug e uma solicitação de melhoria que compartilham contexto, ou tickets de repositórios diferentes ligados ao mesmo incidente ou iniciativa.
O cuidado é não usar “Relates to” como substituto genérico para qualquer conexão. Quando existe uma relação mais precisa, como bloqueio ou duplicidade, a relação específica continua comunicando melhor o estado do trabalho. “Relates to” funciona melhor para associação contextual, principalmente quando a equipe quer preservar os dois itens e tornar a navegação entre eles explícita.
Como reorganizar um fluxo de triagem com as duas novidades
- Mantenha poucas visões compartilhadas e com função clara. Elas devem refletir filas reais do processo, não preferências individuais.
- Crie visões privadas para recortes pessoais recorrentes. Isso pode incluir um conjunto de labels, responsáveis, tipos de issue ou outros filtros usados por uma pessoa no dia a dia.
- Use Relates to quando a associação for contextual. Se a relação for bloqueio, duplicidade ou hierarquia, prefira o vínculo específico.
- Revise automações que interpretam relações entre issues. Como “Relates to” agora aparece em APIs, webhooks, timeline e buscas, integrações podem passar a observar ou processar essa relação quando isso fizer sentido para o fluxo.
- Evite transformar uma organização pessoal em dependência operacional. Se uma fila privada se tornar necessária para outras pessoas, ela deve ser promovida para um mecanismo compartilhado adequado.
O que revisar em automações e integrações
Para times que usam scripts, GitHub Apps ou sincronizações externas, a disponibilidade de “Relates to” em diferentes superfícies merece uma checagem dirigida. A pergunta principal é se alguma automação assume que relações entre issues são apenas de bloqueio, dependência ou hierarquia. Se assumir, talvez seja necessário distinguir o novo tipo de vínculo em vez de tratá-lo como equivalente aos demais.
Também vale revisar consultas de busca e relatórios que tentam reconstruir relacionamentos a partir de texto, labels ou referências manuais. Quando a relação semântica entre duas issues puder ser representada diretamente por “Relates to”, a automação pode depender menos de convenções informais. Isso não significa substituir labels, tipos ou campos, mas usar cada mecanismo para a informação que ele expressa melhor.
Resumo prático
As visualizações privadas ajudam a separar organização pessoal de filas oficiais de triagem. O vínculo “Relates to” ajuda a registrar associação entre issues sem declarar bloqueio, duplicidade ou hierarquia e agora pode ser consumido em mais pontos da plataforma. Para equipes, a combinação permite manter a triagem compartilhada mais enxuta e, ao mesmo tempo, preservar contexto entre tickets de forma estruturada.
Fontes e referências
- 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
