A evolução do GitHub Issues (prévia pública)

• Diversas melhorias foram anunciadas publicamente, como Sub-Issue, Issue Type e busca de issues

Gerencie issues em mais detalhes com sub-issues

• Com sub-issues, é possível detalhar e organizar issues em uma estrutura hierárquica de pai e filho
• As sub-issues podem ser criadas em qualquer issue, e a estrutura aninhada permite acompanhar o progresso e identificar o trabalho restante
• Dentro dos projetos, é possível acompanhar facilmente o progresso das sub-issues

Organize o trabalho com tipos de issue

• Com tipos de issue, é possível classificar e gerenciar issues usando uma linguagem comum compartilhada em todos os repositórios da organização
• Isso permite verificar rapidamente o andamento do backlog de bugs, encontrar todas as iniciativas de alto nível em que a equipe está trabalhando e entender a classificação do trabalho no projeto

Encontre exatamente o que você quer com busca avançada

• Na página de issues do repositório, é possível montar buscas avançadas usando as palavras-chave AND e OR, além de parênteses para buscas aninhadas
• É possível criar filtros mais complexos para encontrar exatamente o conjunto de issues desejado

Atualizações na UI de issues

• A página de índice de issues ganhou uma nova barra de filtros com preenchimento automático e destaque de sintaxe
• Criar várias issues ficou mais rápido com a opção 'Create More', que permite voltar rapidamente à tela de criação
• Agora é possível definir facilmente a ordem desejada com formulários e templates de issues exibidos em ordem alfabética com base no nome do arquivo
• O novo botão 'Copy Link' facilita compartilhar a URL de uma issue
• Em issues longas, ao selecionar 'Load More', agora são carregados 150 eventos em vez de 50

Mais itens nos projetos do GitHub

• Anteriormente, foi anunciada uma beta privada de aumento do limite de itens de projeto, expandindo a capacidade de 1.200 para 50.000 por projeto
• Hoje, esse limite ampliado está sendo disponibilizado para mais casos
• Desde a beta privada, foram adicionados suporte a slices, swimlanes e à API GraphQL, além de correções nos principais relatórios de bugs e melhorias de desempenho
• Se você for administrador de projeto e estiver se aproximando do limite de itens sem usar insights no projeto (o único recurso ainda sem suporte), um banner será exibido no topo do projeto
• Como essa atualização é feita por projeto, e não por organização, é possível participar clicando no botão "Join Waitlist" nos projetos elegíveis

Opinião do GN⁺

• Parece ser uma atualização que leva as ferramentas tradicionais de issue tracking a um novo patamar e pode melhorar bastante a colaboração das equipes de desenvolvimento de software
• O uso de sub-issues traz a vantagem de detalhar o trabalho sem perder a visão do progresso geral, mas uma hierarquia excessivamente profunda pode prejudicar a legibilidade
• É marcante o fato de que a configuração de tipos de issue permite gerenciar issues com uma linguagem unificada dentro da organização. Isso pode melhorar a comunicação e o entendimento entre equipes
• O recurso de busca avançada deve ser útil para encontrar rapidamente as informações desejadas em meio a um grande volume de issues. No entanto, será necessário treinar os usuários para escrever consultas complexas
• O aumento do limite de itens de projeto deve ajudar bastante na gestão de projetos de grande escala. Ainda assim, não é recomendável concentrar itens demais em um único projeto

[GN⁺]

Opiniões do Hacker News

• A maior fraqueza do GitHub Issues é que, ao visitar a página da issue, o relatório original aparece como conteúdo principal

  • Há uma boa chance de que apenas os sintomas sejam descritos, sem uma compreensão real do problema
  • Há uma boa chance de que o autor original não saiba escrever bem um relatório de bug
  • A issue pode continuar aberta porque uma parte pequena ainda não foi resolvida, mesmo depois de o problema principal já ter sido resolvido
  • Seria bom haver um espaço no topo da página explicando o entendimento atual do problema e seu status

• Eu queria usar o GitHub Issues, mas fiquei decepcionado porque ele ficou complexo demais

  • Preocupa a possibilidade de ele se tornar complexo como ADO, Jira e Asana

• Se o Issues fosse restrito aos mantenedores do repositório, ficaria mais fácil contribuir para projetos FLOSS

  • Hoje, o foco se perde por causa de pedidos de suporte, sugestões e conversas
  • Não tenho interesse na “jirificação” das Issues

• Eu criei a última grande atualização do GitHub Issues há 10 anos e esperava mais

  • Parece desenvolvimento baseado em checkbox
  • Inclui React

• É preciso adicionar estados como "closed - duplicate", "closed - won’t fix", "our bot closed this because no one commented on it for 6 weeks"

  • É frustrante quando você encontra o problema e ele já está fechado

• Não entendo a reação negativa

  • Para usuários corporativos, é uma ótima atualização
  • É uma tentativa de alcançar GitLab Issue e Linear

• Já existem labels, então não entendo qual é o propósito dos tipos de issue

• Quando vários problemas são adicionados aos comentários de uma issue, fica difícil acompanhar

  • Existe a opção de adicionar checkboxes [ ], mas não fica claro quem concluiu o quê
  • Também existe a opção de adicionar comentários de revisão a pull requests de código, mas não é possível indicar a pessoa responsável

• O maior problema do GitHub Issues é que grandes projetos open source não conseguem sinalizar facilmente quais issues têm prioridade

  • Uma moderação agressiva é possível, mas gera ansiedade em quem abre a issue
  • É necessário um jeito de distinguir backlog de trabalho a fazer

• Eu gostava da reformulação da lista de tarefas usada no passado

  • Gostava da abordagem mais orgânica de gestão de projetos
  • Fiquei decepcionado quando isso foi transformado em subtarefas explícitas