Obrigado por interagir comigo sobre isso, @Stephen.
Acredito que isso seja muito específico da comunidade
Concordo. É por isso que proponho que seja controlado por uma caixa de seleção nas configurações (seja reutilizando uma das existentes relacionadas a não permitir títulos duplicados ou adicionando uma nova).
Qual é o valor em ter um número menor de tópicos muito mais longos?
Como contexto, em nosso site Discourse, temos uma categoria “Notificações”, cujas subcategorias recebem e-mails enviados por scripts quando certos eventos ocorrem (por exemplo, falhas de teste, novos problemas relatados, novas perguntas postadas no Stack Overflow, novas menções ao nosso projeto em sites de discussão, etc.). Essas categorias são projetadas para permitir que membros da comunidade acompanhem e discutam tipos específicos de eventos que possam lhes interessar.
Em alguns casos, os e-mails gerados por nossos scripts têm linhas de assunto previsíveis e determinísticas por design, como “linux64 testing”. Por exemplo, se tivermos uma nova falha em nossos testes linux64 em 15 de agosto, isso gera um e-mail. Se novas falhas surgirem em 16 de agosto, isso gera um segundo e-mail com a mesma linha de assunto. Então, se todas as falhas forem resolvidas em 17 de agosto, um terceiro e-mail com a mesma linha de assunto é gerado, indicando a resolução. Em seguida, se tivermos novas falhas em 31 de agosto, geramos um quarto e-mail com a mesma linha de assunto, e um quinto quando a falha for resolvida.
Com o comportamento atual do site, cada um desses e-mails gera um novo tópico chamado “linux64 testing”, sem qualquer vínculo ou relação entre eles, dificultando que as pessoas correlacionem os eventos ou decidam qual dos cinco tópicos devem usar para discussão de acompanhamento sobre as falhas. O que gostaríamos é que todos os cinco e-mails (e qualquer discussão de usuário que ocorra neles) apareçam como posts dentro de um único tópico, para que um desenvolvedor possa ver todas as falhas de teste em uma determinada configuração dentro de um único tópico, organizadas cronologicamente.
Outro impacto do comportamento atual do Discourse é que alguém que recebe notificações por e-mail para a categoria ou tópico em questão vê cinco threads não relacionadas em sua caixa de entrada, todas chamadas “linux64 testing”. Enquanto isso, se o Discourse fundisse esses e-mails em um único tópico, essa pessoa veria todos os posts de “linux64 testing” associados como uma única thread em seu leitor de e-mail, tornando muito mais fácil navegar e muito mais parecido com qualquer conversa tradicional.
Executamos várias dezenas de configurações de teste todas as noites, cada uma com uma linha de assunto única quando ocorrem falhas, então a situação atual resulta em algo como uma bagunça extensa e difícil de navegar, com um tópico distinto e superficial por e-mail, todos intercalados cronologicamente. Enquanto isso, nosso ideal seria que a categoria “Notifications.Tests” mostrasse um único tópico por configuração, armazenando todos os posts humanos ou gerados por scripts sobre aquela configuração cronologicamente, conforme determinado por essa linha de assunto única.
[Essa categoria de teste não está atualmente visível publicamente em nosso site, @Stephen, mas se você quiser ver como ela se parece e sentir a dor em primeira mão, ficarei feliz em conceder temporariamente a você acesso de leitura a ela… basta me avisar.]
Para comunidades como a meta, isso significaria que qualquer usuário que envie um e-mail com ‘problemas ao configurar o mailgun’ continuará sendo notificado de atualizações meses ou anos após resolver seu problema.
Concordo que essa escolha pode não ser tão sensata para uma comunidade tão grande e duradoura quanto a meta, que não tem necessidade de agregar posts gerados por e-mail em um único tópico como fazemos. Então, você provavelmente não optaria por um recurso assim, se existisse. (E talvez, com o tempo, um site como o nosso também não o quisesse, pelas mesmas razões, caso em que acredito que o ideal seria poder aplicar a caixa de seleção por categoria, mas não quis pedir demais quando acredito que uma única configuração em todo o site seria suficiente para nós no momento).
Dito isso, mesmo que um site como o nosso optasse por um recurso assim, e o autor original do tópico ‘problemas ao configurar o mailgun’ se sentisse incomodado por posts subsequentes que compartilhassem a mesma linha de assunto, presumivelmente ele poderia se cancelar da assinatura do tópico para evitar continuar recebendo atualizações se/alguém mais usar a mesma linha de assunto (ou simplesmente adicionar outro post ao tópico em questão via interface web)?
[Dito isso, espero que a maioria dos usuários humanos poste pelo site, então imagine que esse recurso tenha um impacto maior em posts gerados por scripts do que em posts gerados por humanos]