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 Contribute > Bug, trabalhamos apenas com a tag fixed. Um post dizendo que algo é duplicado realmente não resolve nada, apesar de ser útil, então eu não acho que seria um bom uso lá também.
Agora, sobre por que usamos fixed em algumas categorias e solved-plugin em outras, acho que isso provavelmente se deve ao que o Moin já disse. As tags são um pouco mais rigorosas 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? Uma automação que adiciona a tag fixed imediatamente se o tópico for fechado e fecha o tópico (ou agenda o fechamento) se ele tiver a tag fixed? Podemos fazer o mesmo em Contribute > UX com as tags fixed e completed.
Existem casos em que fechamos tópicos de Contribute > Bug sem querer adicionar a tag fixed? Vejo que há muitos tópicos de bugs fechados que não têm a tag. Vou dedicar um tempo hoje para investigar.
Uma coisa que gostei no comportamento do plugin solved é que, quando uma solução é selecionada, o tópico é agendado para ser fechado automaticamente 30 dias após a última resposta. Isso é útil porque não é abrupto e permite que as pessoas ainda acompanhem e deem continuidade, caso sintam necessidade. Além disso, provavelmente nos poupa trabalho, pois as pessoas não marcarão o tópico para pedir que 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
Eu passei um tempo analisando isso e vejo que @chapoi tem a ideia certa. Acredito que o que queremos fazer aqui é criar o hábito de marcar os itens como fixed quando forem corrigidos e, em seguida, criar uma automação que defina um temporizador para fechá-los automaticamente, como o plugin solved. Ainda podemos fechar o tópico imediatamente se for necessário, 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 o problema.
Existem tópicos como Rendering 'TypeError' with theme components after update que, na minha opinião, não deveriam receber a tag fixed, pois o bug relatado na OP não foi corrigido. Neste exemplo, não houve reprodução do erro por parte do engenheiro que tentou corrigi-lo.
Também há After deleting a topic, the delete button shows up instead of the restore button, que foi fechado como duplicata. Acredito que, quando Deleting a topic cannot be undone for corrigido, ambos poderão ser marcados como fixed e fechados? Mas como garantir que isso aconteça?
Há muitos tópicos em Contribute > Bug que estão fechados, mas não possuem a tag fixed. Precisaremos revisar esses tópicos retrospectivamente e analisá-los.
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
Eu concordo! Eu também estava pensando na usabilidade quando propus o “sim, e” acima. Atualmente, temos o hábito de simplesmente fechar os tópicos Contribute > Bug quando eles são corrigidos. Isso também corresponde à forma como lidamos com as tarefas internamente.
Gosto da ideia de um botão “corrigido” com 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