Solicitação de Recurso: Estender automaticamente um tópico quando o assunto de um e-mail corresponder ao seu título

Contribuir Funcionalidade
1

Atualmente, se dois e-mails com o mesmo assunto forem enviados para uma determinada categoria do Discourse, cada um cria seu próprio tópico com o assunto como título. Isso acaba gerando múltiplos tópicos com o mesmo título, independentemente de as opções de configuração “Permitir tópicos com títulos idênticos e duplicados…” estarem selecionadas ou não, o que pode resultar em uma infinidade de tópicos com o mesmo título.

O que estou solicitando aqui é que essas postagens geradas por e-mail sejam automaticamente mescladas em um tópico existente quando compartilharem o mesmo assunto, caso a opção “Permitir tópicos com títulos idênticos e duplicados se a categoria for diferente” esteja desmarcada (ou adicionando uma nova opção “mesclar postagens enviadas por e-mail em um tópico existente quando seu assunto corresponder ao título do tópico”). Isso teria o benefício de evitar títulos duplicados em uma categoria, ao mesmo tempo que permitiria que múltiplos e-mails se acumulassem em um único tópico quando compartilharem o mesmo assunto (seja por design ou por acidente).

Na prática, isso ocorre conosco quando temos scripts que geram postagens destinadas a estar relacionadas entre si sob um único tópico, como “tal configuração de teste falhou” ou “alguém mencionou xyz no Reddit”. Seria ideal que todos os e-mails com tal assunto fossem agrupados em um único tópico, em vez de criar um novo tópico por e-mail, cada um com um título idêntico. Também permitiria que alguém adicionasse uma nova postagem a um determinado tópico por e-mail, sem necessariamente precisar responder a um e-mail notificando sobre uma postagem anterior naquele tópico, para pessoas que possam precisar escrever por e-mail em vez de pela interface web, por um motivo ou outro.

Acredito que o potencial de problemas em casos em que humanos enviam acidentalmente e-mails cujo assunto coincide com um tópico existente do qual não tinham conhecimento é baixo. Principalmente porque presumo que, se o assunto deles coincide com o título de um tópico pré-existente, isso se deve a uma similaridade de conteúdo, então não parece ser um grande problema ter isso estendendo o tópico existente em vez de criar um novo com um título duplicado. Além disso, um administrador do site sempre pode marcar a caixa de seleção “permitir tópicos com o mesmo título…” se desejar o comportamento atual de fazer com que cada novo e-mail crie um novo tópico.

Essa funcionalidade seria extremamente útil para nosso site no Discourse, e suspeito que também para outros. Obrigado pela consideração e por toda a excelente engenharia que claramente foi aplicada ao Discourse.

Topics with same title, generated from mail
2

Acho que isso é muito específico da comunidade; pelo seu próprio reconhecimento, colisões não intencionais ocorreriam. Qual seria o valor em ter um número menor de tópicos muito mais longos?

Para comunidades como a meta, isso significaria que qualquer usuário que envie um e-mail com “problemas ao configurar o Mailgun” continuaria sendo notificado de atualizações meses ou anos após resolver seu problema. Isso não parece prático.

O objetivo é evitar títulos duplicados, o que a configuração atual aplica para tópicos criados no site, pois o usuário pode receber feedback no momento da criação do tópico. A configuração não é respeitada para usuários que enviam e-mails porque não há essa oportunidade.

3

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]