Como demonstrado pelo exemplo abaixo, seria útil lá:
3 curtidas
Não tenho certeza se essa é uma boa ideia. Em última análise, nós, como usuários, não podemos corrigir bugs. Isso só pode ser feito alterando o código do Discourse, e isso requer o envolvimento de um membro da equipe. Se isso não for necessário, então Bug provavelmente não é a categoria certa.
Preocupa-me que os usuários marquem as soluções alternativas como a solução. Mas então o bug ainda não seria corrigido. Seria, portanto, mais confuso do que útil. No seu exemplo, o problema também não é resolvido, pois já existe um relatório de bug. Acho que mesclar os tópicos é o melhor neste caso. Dessa forma, todos os usuários serão notificados quando houver uma correção, independentemente do tópico que eles originalmente seguiram. Às vezes, faz sentido fechar um tópico com uma referência ao outro, mas então os likes que apoiaram o tópico fechado são perdidos, o que é triste quando os usuários afetados são determinados por likes.
3 curtidas
Na categoria Bug, trabalhamos apenas com a tag fixed. Uma postagem dizendo que algo é duplicado não resolve nada, apesar de ser útil, então não acho que teria sido um bom uso lá também.
Agora, por que usamos fixed em algumas categorias e o plugin solved em outras, acho que isso se deve provavelmente ao que Moin já disse. As tags são um pouco mais rígidas no uso, então apenas a equipe pode decidir quando algo está corrigido.
5 curtidas
Obrigado pela sugestão! É sempre bom verificar a forma como as categorias são configuradas, então aprecio que você tenha pensado nisso e iniciado este tópico.
Como Moin e Charlie apontaram, nossa equipe confia em fixed e no fechamento de tópicos (ações disponíveis apenas para nós) para nos comunicarmos com a comunidade de que um bug foi, bem, corrigido! Isso parece estar funcionando muito bem e é uma forma de mantermos um backlog bastante óbvio de bugs que precisam ser corrigidos.
É verdade que na categoria de bugs, uma pessoa que pode fornecer uma solução não recebe crédito por isso da mesma forma que receberia em categorias com o plugin de solução ativado, o que é uma pena. Na categoria de bugs, a pessoa que relata o bug recebe um distintivo por isso se for curtido por um membro da equipe do Discourse. Mas outros que ajudam ao longo do caminho, fornecendo passos para reproduzir, apontando duplicatas, sugerindo soluções e assim por diante, não receberão crédito. Algo para se pensar.
Neste caso, teria sido bom que você pudesse dar crédito a Moin por apontar que o relatório é uma duplicata, mas manter o tópico também cria algum ruído extra que tornará a análise de todos os relatórios de bugs abertos um pouco mais complicada para a equipe. Então, espero que você não se importe, mas defini um temporizador para excluí-lo.
1 curtida
@tobiaseigen, não é para isso que serve o recurso de bloqueio? Excluí-lo fará com que alguns URIs externos que apontam para ele retornem 404, o que não é ideal.
Não guardamos tudo! 
Não se preocupe muito com o 404.
Nós não praticamos isso de forma consistente, pois é trabalho extra. Acho que há mérito em marcar automaticamente com “fixed” quando fechamos, então para casos atípicos em que não corrigimos, podemos editar com uma tag especial.
Isso exigirá alguma nova automação.
4 curtidas
Eu já passei por isso várias vezes, procurando informações, vendo um link que parecia interessante, mas que levava a um 404 ao ser clicado, o que foi bastante desagradável.
Nesse caso, eu sinalizaria a postagem, que seria editada/removida por um moderador.
Para evitar isso, antes de excluir um tópico, dê uma olhada na seção de links da primeira postagem:
E então, agindo preventivamente para remover essas referências de link seria o melhor, mas também exigiria mais trabalho.
2 curtidas
Propus o inverso a @tobiaseigen: ao adicionar a marcação fixed, fechar automaticamente; o mesmo que para solved.
Talvez a resposta seja um sim, e? Automação que adiciona a tag fixed imediatamente se for fechada e fecha o tópico (ou agenda seu fechamento) se tiver a tag fixed? Poderíamos fazer o mesmo em UX com as tags fixed e completed.
Existem casos em que fechamos tópicos Bug sem querer adicionar a tag fixed? Vejo que há muitos tópicos de bugs que são fechados, mas não têm a tag. Vou dedicar um tempo hoje para explorar.
Uma coisa que gostei na forma como o plugin solved se comporta é que, quando uma solução é selecionada, o tópico é agendado para ser fechado automaticamente 30 dias após a última resposta. Isso é útil porque é abrupto e permite que as pessoas ainda possam dar seguimento, caso ainda sintam necessidade. Isso também provavelmente nos poupa trabalho, pois as pessoas não sinalizarão o tópico para pedir que ele seja reaberto.
1 curtida
O motivo pelo qual não gosto do fechamento => adicionar tag automaticamente é por causa dos casos de uso em que não foi corrigido ou é um “wont-ever-fix” (nunca será corrigido). Sinto que fazer 1 ação (“adicionar tag”) que então define automaticamente o timer do tópico para fechar após 30 dias é a maneira ideal.
2 curtidas
Passei algum tempo com isso e vejo que @chapoi tem a ideia certa. Acho que o que queremos fazer aqui é criar o hábito de marcar itens como fixed que foram corrigidos e, em seguida, criar uma automação que definirá um temporizador para fechar automaticamente, como o plugin solved. Ainda podemos fechar o tópico imediatamente, se for justificado, mas em alguns casos, acho que é bom mantê-lo aberto por um pouco mais de tempo para dar às pessoas a chance de testar e relatar se ainda estão enfrentando um problema.
Existem tópicos como Rendering 'TypeError' with theme components after update que acho que não deveriam receber a tag fixed, porque o bug relatado no OP não foi corrigido. Neste exemplo, não houve repro do engenheiro que tentou corrigi-lo.
Há também After deleting a topic, the delete button shows up instead of the restore button que foi fechado como duplicado. Suponho que quando Deleting a topic cannot be undone for corrigido, ambos poderão ser marcados como fixed e fechados? Mas como garantimos que isso aconteça?
Existem muitos tópicos em Bug que estão fechados, mas não têm a tag fixed. Queremos revisar e analisar esses retrospectivamente.
3 curtidas
Meu problema aqui é a usabilidade. Quero que os engenheiros tenham uma solução de um clique aqui.
- Clique em “Corrigido” em Ações do Tópico ou Ações do Tópico de Administrador.
- A mágica acontece:
- Timer do tópico criado para fechar em 1 dia útil
- Tópico marcado com “corrigido”
Não sou fã da experiência do usuário apenas para “marcar tópico”, pois é de alto atrito.
- Navegue até o topo do tópico
- Clique no título
- Clique na caixa de tags
- Pesquise por “corrigido”
- Adicione “corrigido”
- Clique na caixa de seleção
Isso é muito atrito.
Ficarei feliz em adicionar este fluxo, mas precisaremos de um componente de tema para isso ou algum tipo de automação que introduza esta interface (que também pode ser útil).
4 curtidas
Estou com você! Eu também estava pensando na usabilidade quando propus “sim, e” acima. Atualmente, temos memória muscular em torno de simplesmente fechar tópicos de Bug quando eles são corrigidos. Isso também corresponde à forma como lidamos com os “to-dos” internamente.
Gosto da ideia de um botão “corrigido” de um clique.
1 curtida
E a comunidade entregou 
6 curtidas
Legal! Experimentei o componente de tema do Nate no meu site pessoal e ele faz o que promete. Ótimo trabalho e implementado rapidamente também! 
Para poder usá-lo aqui, teríamos que ser capazes de limitá-lo a uma categoria. Se decidirmos que essa abordagem funciona bem, também gostaríamos de poder criar mais de um botão.
Para sua informação, Sam também está trabalhando em uma implementação experimental que é diferente e muito mais flexível, usando automação.
2 curtidas
Acho que essa mudança nos ajudaria bastante aqui no meta. Fiz um acompanhamento interno para ver se ela pode ser implementada usando a implementação experimental do Sam com automação ou fazendo um fork do componente de tema do Nate e usando-o aqui.
O componente do Nate faz efetivamente a mesma coisa e é muito bom, mas teríamos que fazer um fork dele porque não instalamos componentes ou plugins de terceiros no meta. 
1 curtida
Se você fizer isso, a coisa honrada a se fazer seria oferecer a Nate um token financeiro de agradecimento - como você faz para riscos de cibersegurança identificados via HackerOne.
2 curtidas
Vamos manter este tópico focado em se a comunidade se beneficiaria do uso de algo como o componente temático do Nate. Se sim, resolveremos a mecânica com o Nate.
Ficarei feliz em criar outro tópico sobre como os contribuidores de código aberto são recompensados por seu trabalho de forma mais geral, se você quiser.
2 curtidas