Por que os usuários não podem criar Issues diretamente

• No repositório do Ghostty, os usuários não podem criar Issues diretamente e devem primeiro iniciar a discussão no GitHub Discussions
• O projeto não usa o rastreador de Issues para discutir bugs ou pedidos de funcionalidade, e todas as discussões acontecem no Discussions
• Quando a discussão fica suficientemente específica e organizada como um item acionável, um mantenedor a converte em Issue
• Esse modelo ajuda mantenedores e contribuidores a encontrar rapidamente issues em que realmente é possível trabalhar
• Como a maioria dos relatos é, na prática, problema de ambiente do usuário, mal-entendido ou pedido de recurso ainda não implementado, esse procedimento é importante para o controle de qualidade do projeto

---

Política de restrição na criação de Issues

• No repositório do Ghostty, os usuários não podem criar Issues diretamente
  • Em vez disso, devem primeiro compartilhar o problema ou a sugestão no GitHub Discussions
  • Depois que um mantenedor analisa a discussão e confirma que se trata de um problema claramente reproduzível, ele a converte em Issue
• Esse modelo existe para manter o rastreador de Issues contendo apenas itens realmente acionáveis
  • Como todas as Issues já chegam com escopo bem definido, os contribuidores podem começar a trabalhar imediatamente

Princípios de operação do rastreador de Issues

• O Ghostty não usa o rastreador de Issues para discussões nem para pedidos de funcionalidade
  • Pedidos de funcionalidade e perguntas gerais são tratados no Discussions
  • As Issues contêm apenas bugs claramente definidos ou itens de trabalho acionáveis
• Essa abordagem é um princípio operacional formado com base na experiência de manutenção de projetos open source
  • Pela experiência anterior, 80% a 90% dos relatos de usuários não eram bugs reais, mas mal-entendidos ou problemas de ambiente
  • A maior parte do restante era de pedidos de funcionalidade ainda não implementados, que muitas vezes exigiam especificações adicionais

Melhoria da eficiência de manutenção

• Ao passar pela etapa de Discussions, os mantenedores conseguem gerenciar como Issues apenas problemas já validados
  • Isso reduz relatos duplicados desnecessários ou bug reports incorretos
  • A lista de Issues fica organizada em torno de itens em que já é possível trabalhar imediatamente
• O usuário não precisa fazer trabalho extra mesmo quando encontra um problema válido
  • O mantenedor faz a conversão direta para Issue e segue com o tratamento

Documentação de referência

• O procedimento detalhado e as diretrizes de contribuição podem ser consultados no arquivo CONTRIBUTING.md
• O documento especifica como participar do Discussions e quais são os critérios para conversão em Issue

[GN⁺]

Opiniões no Hacker News

• Concordo 100%. Se for o projeto de outra pessoa, a autoridade para decidir o que é issue pertence inteiramente a ela
  Quanto maior o projeto, mais aparecem pessoas que não leem as mensagens, fazem pedidos estranhos e até casos de inflar CVEs com IA

  • Eu realmente não entendo quem não lê a mensagem de erro
    Mesmo que o usuário não saiba o significado do erro, pelo menos precisa dizer qual erro apareceu
    Lembro de um caso em que, durante um teste, eu informei explicitamente “broken pipe error”, mas o engenheiro fechou como “não reproduzível” e depois disse que não conseguia reproduzir justamente por causa do mesmo erro
  • O Github Issues tem limitações como bug tracker
    A maioria dos trackers permite classificar com estados como “unconfirmed”, mas o Github é um sistema de discussão simples, então fica difícil de gerenciar
  • Já recebi um relatório de CVE logo depois do lançamento do ChatGPT
    Passei 4 horas refutando com código e evidências, e a resposta que voltou foi “shrugs AI”
  • Muitos usuários querem apenas o resultado, sem tempo para aprender o uso correto da ferramenta
    A “Facebookization” criou a percepção de que tudo se resolve com alguns cliques, e agora a “LLMization” parece que vai piorar isso ainda mais
    Esse tipo de abordagem não combina com software profissional, mas a expectativa já foi moldada assim
  • Um bom issue tracker deveria ter recursos para filtrar esse tipo de ruído
    O fato de o Ghostty classificar pedidos por meio de discussões é uma abordagem diferente, mas válida

• A investigação do vazamento de memória está espalhada por várias plataformas
  Link X 1, Link X 2, Discussão 1, Discussão 2
  Ainda não foi promovida a issue oficial

  • Desisti de usar o Ghostty por causa do vazamento de memória
    Mesmo em um sistema com 8 GB, bastava abrir o terminal algumas vezes para faltar memória
    O Foot tem menos recursos, mas era muito mais estável
  • Segundo o primeiro link, o autor diz que esse problema só foi relatado duas vezes
    O segundo link parece apenas uma tentativa de provocar discussão
  • Eu também relatei esse problema em uma discussão, mas não houve resposta
    Analisei os logs com Claude Code e corrigi provisoriamente; agora só consigo reproduzir em 1 de cada 10 vezes
    Espero que isso ajude quando alguém investigar mais a fundo
  • A compatibilidade de GPU também é complicada
    Há problemas até com GPU integrada, mas sempre colocam a culpa no GTK ou na Nvidia
  • Parece que os contribuidores ainda acham que faltam condições claras de reprodução para abrir uma issue

• Acho ineficiente a separação entre “Issues” e “Discussions”
  É preciso fazer buscas duplicadas, e não dá para mover tickets
  Se fizer follow-up por e-mail, as notificações se perdem
  Por isso desativei Discussions no meu projeto

  • Discussions é útil como espaço para perguntas simples ou problemas de instalação
    Se for um bug de verdade, aí pode virar issue
  • Esse processo também pode ser implementado com um sistema de labels
    Basta o administrador aplicar a label “bug”
  • Não é preciso verificar duplicatas
    Quando a discussão estiver organizada, aí se cria a issue
  • Na verdade, issues e discussões podem ser convertidas uma na outra
    As notificações também são mantidas
  • Como na estrutura do Ghostty, acho uma separação razoável deixar Discussions aberto a todos e Issues sob gestão dos mantenedores

• Alguns grandes projetos da comunidade Python também usam esse método
  Mas, do ponto de vista de usuários avançados, o processo de reportar bugs é incômodo
  A postura de “nosso projeto é perfeito” soa arrogante

  • É difícil entender essa reclamação
    A maioria dos drive-by bug reports não serve para nada e só gera ruído
    Se a intenção é realmente contribuir, é melhor corrigir bugs já definidos
  • Arrogante? Pelo contrário, são pessoas que investem tempo e esforço de graça
    É natural impor limites sobre como os relatórios devem ser feitos
  • Se você encontra bugs com tanta frequência, talvez valha a pena participar diretamente do projeto
  • Por outro lado, ter certeza de que “isso é obviamente um bug” também pode ser um tipo de arrogância
  • Abrir uma discussão é mais trabalhoso do que abrir uma issue? Não sei

• Sobre a afirmação de que toda issue deve estar pronta para ser trabalhada,
  surgiu a pergunta: “então por que não colocar uma tag ‘ready-to-be-worked-on’?”

  • Mas o Github não permite definir a visualização padrão como “triage”, e em projetos grandes o gerenciamento de issues é ineficiente
    Esse sistema foi muito mais bem-sucedido
  • O modelo por tags exige várias rodadas de feedback, então os detalhes ficam espalhados nos comentários
  • Se qualquer pessoa puder comentar, surge barulho desnecessário
    Por isso separaram o espaço dos desenvolvedores e o espaço dos usuários
  • Mesmo que se feche uma issue errada, ela pode ser reaberta, e no fim a lista de issues fica impossível de administrar
  • Não faz sentido forçar o workflow de outra pessoa com “por que o meu jeito é melhor”

• Issues ficam impossíveis de gerenciar quando a escala cresce
  Usar Discussions como filtro é eficiente

  • Mas no fim os mantenedores ainda precisam ler e classificar tudo, então o volume de trabalho é parecido
    As duas funções do Github têm praticamente a mesma interface
    Só que Discussions tem recurso de upvote
  • Também houve a reação cínica: “não seria mais eficiente simplesmente fechar automaticamente toda issue depois de 2 semanas?”
  • Até um grande projeto como o Curl tem só 5 issues abertas
    curl/curl/issues

• Há também quem diga que esse modelo deveria ser o padrão
  O ideal seria uma estrutura em que a comunidade cuida das discussões e os contribuidores cuidam das issues

  • Mas isso é apenas uma realocação do processo; a essência continua a mesma
    O sistema de labels do GitHub já dá conta disso
    Documentação de gerenciamento de labels do GitHub
  • Em vez de definir um “padrão”, é melhor que cada projeto experimente naturalmente e encontre o método adequado
    Como em um Natural experiment

• Concordo com a política de submissões de usuários
  Quando se olha as discussões fechadas, parece parecido com issues fechadas, mas pelo menos o ruído na aba de issues diminui
  Lista de discussões fechadas do Ghostty

  • Todo relato de usuário começa em discussões e, se for confirmado como bug real, vai para issues
    Muitas discussões não chegam a esse estágio, mas os problemas dos usuários são resolvidos
    Acho essa estrutura de separação um design bem inteligente

• Na verdade, “não poder abrir issue” não é um recurso do GitHub,
  mas apenas uma mensagem de template dizendo “não abra uma nova issue; use Discussions”

• Já vi esse método em outros projetos,
  e essa estrutura que usa discussões como ponto de partida parece bastante razoável
  Só que muitos projetos ainda não ativaram o GitHub Discussions

[iolothebard]

Qual é a diferença entre essa discussão e uma issue? Issue não é sinônimo de “bug”. Seja bug, sugestão de funcionalidade ou PR... se há algo a ser discutido, então é uma issue.
Se não vale a pena discutir, basta fechar.

[nemorize]

Não é porque discussions e issues sejam diferentes, mas provavelmente porque separar em abas diferentes era simplesmente mais do gosto deles.

Postar na aba de issues tanto uma espécie de lista de tarefas quanto discussions, e gerenciar isso com tags
vs
usar a aba de issues apenas como lista de tarefas, e discussions apenas como discussions