Cabeçalhos para notificações de e-mail para que usuários do Gmail possam filtrar por tags?

Contribuir Funcionalidade
,
1

A postagem foi fechada como duplicata Email: cabeçalhos de e-mail devem ter tags, possivelmente em referência a Customs email headers and/or subjects tags, mas este último é um tanto geral, e eu gostaria de falar sobre um problema específico que temos:

Estamos usando tags como a substituição mais lógica para dezenas de listas de e-mail sobre vários subtópicos do projeto. Começamos a usar categorias, mas isso se tornou difícil de gerenciar — categorias são pesadas, não permitem postagem cruzada fácil e, por uma série de outras razões, achamos que as tags são uma melhor opção.[1]

No entanto… há um problema. Embora seja possível colocar %{optional_tags} no modelo para notificações por e-mail, o filtragem muito limitada do Gmail não faz nada inteligente com isso — e, mesmo para o usuário de e-mail old-school, é um pouco chato escrever uma regra procmail que analise a linha de assunto e a analise.

Portanto, seria bom ter a tag em outro lugar. Para o pessoal do procmail, um cabeçalho X-Tags personalizado serviria, mas o Gmail não se importará, então precisamos de outra coisa.

Uma ideia seria usar as tags como List-ID, mas não tenho certeza se o Gmail faz a coisa certa com várias tags List-ID múltiplos campos List-ID não são permitidos [2]. Outra ideia, que é um pouco improvisada, mas acho que funcionaria: colocar tag@subdominio.exemplo.com (e potencialmente também tag2@subdominio.exemplo.com, tag3@subdominio.exemplo.com, …) na lista CC. O Google pode filtrar isso, e a maioria dos outros sistemas também tem recursos razoavelmente avançados para lidar com CC como um campo multivalorado. E, redirecionaríamos qualquer e-mail realmente enviado para esses endereços para o nada[3].

Como bônus, a abordagem CC poderia ser usada como uma maneira de adicionar tags em e-mails de entrada (veja Add tags by email). Novamente, um pouco improvisado, mas, então, tudo em e-mail é, em 2022.

  1. Se você quiser discutir isso, posso… em outro tópico assunto! ↩︎

  2. maldito seja você, RFCE 2919! ↩︎

  3. ou seja, /dev/null ↩︎

2 curtidas
2

Estou aberto a quaisquer outras sugestões ou ideias que alguém tenha. Não podemos razoavelmente sugerir uma mudança em larga escala para o Discourse sem isso.

3

Além disso, por que não há tags aqui? :slight_smile:

4

Parece que eles podem funcionar, mas você precisará de um plugin personalizado.

5

Qual é exatamente o seu caso de uso?

Eu estaria interessado em saber por que você sente a necessidade de ajudar as pessoas a filtrar notificações por e-mail do seu site. O uso pretendido do Discourse é que os membros da comunidade simplesmente usem notificações por e-mail para serem informados quando houver atividade de que eles se importam e cliquem no link para fazer login quando quiserem participar das discussões. Para sites que desejam isso, a resposta por e-mail pode ser ativada. Mas o membro ainda deve ter o hábito de fazer login para continuar a discussão no site.

Dessa forma, todos se beneficiam e podem contribuir para o esforço colaborativo de organizar e gerenciar discussões no site. E você não acaba com um monte de discussões desatualizadas isoladas nas pastas de e-mail de todos. Quando o Discourse é usado como pretendido, as notificações recebidas por e-mail podem simplesmente ser excluídas.

O e-mail também é notoriamente difícil de acertar, e não apenas para o Discourse. Quanto mais você conseguir fazer com que sua comunidade faça login e se envolva em seu site, mais bem-sucedida (e fácil de gerenciar) sua comunidade será.

Talvez o Discourse não seja a escolha certa para sua comunidade, ou você precise manter algumas listas de e-mail operacionais enquanto constrói seu site Discourse? Sei que pode ser difícil mudar os hábitos de comunidades de longa data.

Boa sorte! :sunflower:

2 curtidas
6

Acho que isso pode estar certo.

Vocês ainda têm o pessoal do procmail? E o pessoal do Gmail, e o pessoal do Discourse? Manter todos esses três grupos felizes será muito difícil mesmo.

Se você tem um orçamento de US$ 2000-5000, então talvez consiga um plugin personalizado que faça o que você pede, mas é difícil imaginar que será satisfatório para alguém. Você não sabe que outros problemas surgirão assim que resolver os que você conhece agora. Lembro-me de gerenciar listas de e-mail quando um monte de gente usava gateways de e-mail baseados em rede local que não seguiam o RFC-822 (foi quando eu usava procmail e rmail do emacs). O problema é simplesmente insustentável.

Eu recomendaria apenas usar categorias. Ou, se você realmente quiser listas de e-mail que sigam as convenções de algumas décadas atrás, apenas mantenha o que funciona.

2 curtidas
7

Se esses recursos já existem em outras plataformas que estão enraizadas no modelo tradicional de lista de e-mail, você provavelmente terá mais sucesso lá, em vez de pedir que sejam adaptados a um produto mais voltado para o futuro.

Ou, para colocar de outra forma, se isso é um impedimento, por que considerar o Discourse em primeiro lugar? O HyperKitty poderia ser estendido para adicionar a funcionalidade que você precisa?

1 curtida
8

Objetivo

Atualmente, o Fedora tem centenas de listas de e-mail, com cerca de 90 com algum grau de atividade, e um punhado que são muito ativas. Quero consolidar tudo isso em um só lugar, o que inclui trazer nossa comunidade de contribuidores junto com sucesso. Se houver uma opção melhor que o Discourse para isso, ninguém a criou ainda.

Versão curta

Tenho trabalhado ativamente nisso por três anos e pensando nisso por pelo menos dez. Ao conversar com pessoas da minha comunidade sobre o que as bloqueia, essa coisa específica surgiu repetidamente.

Versão longa:

Quase na mesma época em que o Discourse começou[1], criamos uma interface gráfica para o Mailman3 chamada Hyperkitty, destinada a ser uma interface web moderna que as pessoas pudessem usar para acessar as listas de e-mail subjacentes. Você pode ver isso em ação na Lista Devel do Fedora.

O Hyperkitty tem algumas ideias interessantes, mas não foi realmente financiado na escala necessária para ter sucesso, e acabou sendo lançado com o design inicial e sem provisão para melhorá-lo e corrigi-lo em uso real. E ele usa o e-mail como base subjacente, e isso realmente limitou as coisas[2] — mesmo que tivéssemos os recursos, manter isso como o maior denominador comum[3] teria sido um limite frustrante.

Então, eu entendo onde você está com isso. Se você fizer uma viagem pela Wayback Machine pelo histórico do discourse.org, você pode ver[4] que o Discourse se apoiou bastante em lições aprendidas com fóruns e listas de e-mail e na substituição de ambos…

2013

… e isso sobreviveu em grande parte até hoje, embora haja menos conversas outras sobre listas de e-mail nas várias páginas. Você passou pela mesma coisa que teríamos passado se tivéssemos recursos para investir no Hyperkitty — o problema do e-mail como a base mais baixa — e chegou à conclusão lógica. Eu totalmente entendo de onde você vem ao dizer explicitamente agora que levar as pessoas para o site é o uso correto.

Atualmente:

  • Temos dezenas de listas de e-mail ativas
    • com centenas de participantes ativos
    • e muitos milhares de assinantes passivos.
  • Essas listas remontam literalmente a mais de 20 anos.
  • Muitas pessoas de código aberto da velha guarda realmente se apegam a essa forma de trabalhar.
    • é familiar,
    • já está configurado e
    • chega a uma rotina diária sem a necessidade de adicionar “verificar algum site”
  • muitas pessoas estão ativas em diferentes partes do projeto, mas essa “pegada” é muito individual

Mas:

I. Essas listas são menos funcionais do que muitas pessoas pensam:

  • a moderação é quase impossível (no máximo um grande porrete “tudo ou nada”)
    • apesar dos esforços, as pessoas nem sempre seguem os padrões que esperamos
  • mega-threads não são uma boa discussão
  • o assédio fora da lista é fácil de iniciar e fora do nosso controle
  • o cross-posting é uma bagunça, pois as assinaturas não são consistentes
  • impossível de acompanhar, a menos que você esteja comprometido
  • pessoas que deveriam participar não o fazem por várias razões mistas acima

II. E-mail não é o futuro

  • As listas de e-mail são em grande parte opacas para os motores de busca e não parecem “atividade real” para a maior parte do mundo
  • Novas pessoas não querem se inscrever em listas de e-mail.[5]
  • A “cultura” de lista de e-mail não é realmente uma coisa anymore.[6]
    • E a interface web do Gmail é ativamente hostil a convenções tradicionais como respostas inline.

III. O e-mail em geral está condenado

  • Grandes provedores têm a escala para “resolver” o spam para si mesmos, e agora têm anti-incentivos para resolvê-lo globalmente.
  • Pequenos provedores têm chances decrescentes de entregar de forma confiável.
  • Listas de e-mail inerentemente republicam, e toda a infraestrutura de assinatura e verificação realmente não se importa.
  • As empresas estão mudando para Slack e similares para comunicação funcional, deixando o e-mail para anúncios e transmissões.
    • e Jira e github e assim por diante para interações focadas em fluxo de trabalho.
  • Novamente, as pessoas “normais” não o usam para nada além de receber avisos sobre várias coisas de empresas das quais são clientes. Não é realmente para comunicação pessoal anymore.

Mas ainda há uma necessidade

Temos conversas em tempo real cobertas[7], mas ainda precisamos de conversas assíncronas e de longa duração que as listas de e-mail forneceram. O chat não cobre tudo, não funciona bem globalmente e com voluntários com compromissos de tempo variados. E as ferramentas de fluxo de trabalho são muito restritas.

O Discourse é realmente a melhor opção

  • Listas de e-mail não são um futuro viável.

  • O Hyperkitty está preso em 2014.

  • Temos muito para usar apenas Github / Gitlab.

  • Outras possibilidades não servem:

    • Ponymail sofre do mesmo problema de e-mail como GCF
    • Vanilla não é ótimo. Vou deixar por isso mesmo. :slight_smile:
    • Google Groups é o pior de tudo.

  • No lado positivo para o Discourse: muitas outras comunidades de código aberto estão se consolidando em torno dele. Notavelmente: Python, GNOME…

Entra Cassandra

Não o banco de dados — quero dizer, contar às pessoas sobre a desgraça, mas ninguém acredita. Ouço muito “E-mail funciona bem”, e “Não vejo problema com listas de e-mail”, e, claro, “Eu odeio fóruns”, ou mesmo especificamente “Eu não gosto do Discourse”.

Mas, realmente precisamos de mudança.

Então…

Preciso fazer com que uma comunidade de código aberto grande, ativa e importante mova sua plataforma principal de comunicação de projeto para o Discourse, e muitas pessoas estão céticas. É uma grande mudança. Quero tornar isso o mais fácil possível, tanto para tornar mais fácil e agradável para as pessoas céticas, mas dispostas a tentar, quanto para tornar possível tentar para as pessoas que têm interação por e-mail — incluindo filtragem — como um bloqueador pessoal.

Acho que uma vez que estejam lá, muitas pessoas ajustarão seus comportamentos — teremos mais pessoas descobrindo que interagir diretamente com o site não é tão ruim.[8] E temos nosso próprio sistema de notificação de todo o projeto que tenho planos de integrar, e espero que isso possa eventualmente dar às pessoas mais do que elas realmente precisam.

Mas, enquanto isso, eu preciso dar às pessoas o que elas estão pedindo.

  1. Na verdade, tentei sugerir o Discourse como uma abordagem alternativa naquela época, em vez de criarmos a nossa própria. Se eu tivesse uma máquina do tempo, talvez voltasse e insistisse ainda mais. Mas eu não estava no meu cargo atual naquele momento e o destino já estava traçado… ↩︎

  2. Lição semelhante de LUGNET, acho que o software de fórum mais incrível e sensato dos anos 90 — mas atrelado ao NNTP como backend. ↩︎

  3. Eu sei que o idioma é “menor denominador comum”, mas isso não faz sentido. Como “eu poderia me importar menos”, mas agora também com matemática. ↩︎

  4. Quer dizer, se você já não se lembra, é claro! ↩︎

  5. Na Coreia, e-mail é para velhos chegou para todos nós! ↩︎

  6. Não consigo me lembrar da última vez que ouvi alguém dizer “netiqueta”. ↩︎

  7. usando Matrix, em https://chat.fedoraproject.org/… ↩︎

  8. Embora, nós definitivamente temos esta pessoa, então não serão todos. ↩︎

5 curtidas
10

Ótima redação! :ok_hand:

Você pode descrever a filtragem sobre a qual está falando com um pouco mais de detalhe, que as pessoas estão usando em seus e-mails? Eu também estou por aqui há um tempo e já administrei listas do Mailman e participei (e ainda participo) de muitas listas de e-mail, mas nunca encontrei filtragem automática usando cabeçalhos. Parece-me que, se alguém se inscreve em uma lista e quer filtrá-la em uma pasta em seu e-mail, eles mesmos configurariam isso, lista por lista. Você pode fazer isso com o Discourse também, certo?

Acho que as categorias funcionam muito bem como substitutas para listas de e-mail, com o modo de lista de e-mail ativado pelo usuário ou o usuário acompanhando certas categorias para receber e-mails para cada postagem. Talvez precisemos aprender um pouco mais também sobre por que você acha que organizar discussões em tags é melhor e vale o esforço para obter paridade com como já funciona com categorias.

Editar: Lembrei-me da minha antiga postagem sobre isso, de 2014! :scream:

1 curtida
11

Claro. Os cabeçalhos que o Discourse define atualmente se parecem com isto (de uma notificação real deste tópico):

List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/efed8ca1777379c660afc031464b98eb4e6fa2323a71fa12fa2269eeca5b0905>
X-Discourse-Post-Id: 1216779
X-Discourse-Topic-Id: 249982
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Discourse Meta | feature <feature.meta.discourse.org>
List-Archive: https://meta.discourse.org/t/headers-for-email-notifications-so-that-gmail-users-can-filter-on-tags/249982
Feedback-ID: meta:user_replied:discoursemail

Se não fosse pelo Gmail, adicionar algo como:

X-Discourse-Tags: alguma-tag, outra-tag

Veja Customs email headers and/or subjects tags - #6 by mattdm — se a configuração email custom headers fosse passada através da expansão de modelo para que X-Discourse-Tags: %{optional_tags} funcionasse, esta parte já funcionaria.

E, para usuários de procmail e outros clientes de e-mail old-school, isso seria suficiente. Infelizmente, por quaisquer razões insondáveis do Google, o Gmail não pode filtrar em tags arbitrárias e está (até onde eu sei) limitado a To:, From:, Cc: e … felizmente, pelo menos, List-ID. Como esse é o elefante branco, para acomodar esses usuários, definir List-ID por tag em vez de categoria (ou, em combinação?) é o melhor que consigo pensar.

No entanto, o RFC 2919 diz que apenas um List-ID é permitido por mensagem. Então, isso deixa::

  1. Escolher uma tag arbitrariamente[1]
  2. Gerar algo incluindo todas as tags, como List-ID: primeira_tag_segunda_tag.discourse.example.org e deixar os usuários descobrirem. [2]
  3. Gerar múltiplos e-mails por notificação, um para cada tag e diferindo apenas neste cabeçalho[3]
  4. Deixar o List-ID se referindo à categoria e, em vez disso, usar a ideia do CC… [4]

Eu realmente não gosto de nenhuma dessas opções. Então, como um primeiro passo, X-Discourse-Tags: cobriria pelo menos os usuários que não usam Gmail. (O que provavelmente é uma boa sobreposição com usuários resistentes à web, então acho que vale a pena fazer para ver até onde isso nos leva.)

  1. confuso! ↩︎

  2. não é ótimo ↩︎

  3. também não é ótimo ↩︎

  4. Muito complicado. Apenas adicionar Cc: %{optional_tags}[4] não funcionaria, porque precisaria ser expandido para que cada tag correspondesse a um endereço de e-mail real (buraco negro). ↩︎

3 curtidas
12

Sim, muito mesmo! Seu último parágrafo resume tudo muito bem!

2 curtidas
13

Muito favorável à adição de X-Discourse-Tags e X-Discourse-Category (para paridade)

Acho que a longo prazo para o Gmail poderíamos adicionar uma opção ao usuário:

  • Por favor, adicione todas as tags a que este tópico pertence nos títulos dos tópicos enviados por e-mail.

Por exemplo, algo como:

[Discourse Meta] [feature] [email] [notifications] Header for email notifications

Ou talvez quando habilitado:

[Discourse Meta] Header for email notifications … [feature] [email] [notifications]

5 curtidas
14

Sim, isso seria interessante como uma opção do usuário. Atualmente, temos isso em todo o site:

%{optional_re}%{topic_title} [Fedora] %{optional_pm}%{optional_tags}

Recebemos um feedback forte de que colocar as tags em qualquer lugar que não fosse por último era irritante. E algum feedback de que o Google não é muito inteligente ao filtrar linhas de assunto parciais de forma útil.

Não tenho certeza do quanto podemos “consertar” o Google (Ou melhor, tenho certeza, e é “muito pouco”). Portanto, pode haver algum grau de “ah, bem” que terei que convencer as pessoas a aceitar.

4 curtidas
15

Existem algumas pequenas coisas que podemos fazer para melhorar a situação.

No momento, estamos

  1. Limitando a 3 (ordem arbitrária)
  2. Não envolvendo tags em [ ]

Estou indeciso, mas acho que o limite arbitrário de 3 não é bom, deveríamos simplesmente removê-lo.

Além disso, tags.map{|t| \"[#{t}]\"}.join(\" \") seria melhor, pois o filtro poderia ser em [tagname] em vez de tagname, que é muito mais provável de aparecer no título da MP.

@martin, o que você acha?

5 curtidas
16

Isso faz mais sentido sabendo o histórico. Parece que você tem um orçamento para fazer as coisas acontecerem e algumas boas ideias para chegar mais perto do início. Acho que será difícil, e importar todos os dados será um desafio. Ainda assim, será difícil deixar todas essas pessoas felizes e Sam está a bordo com pelo menos algumas de suas ideias, então elas entrarão no núcleo e não serão quebradas no futuro, como provavelmente aconteceria com um plugin.

3 curtidas
17

Concordo com você aqui, embora eu pense que, em vez de remover o limite completamente, podemos apenas usar a configuração max_tags_per_topic? Acho que seria mais seguro.

Infelizmente, adicionar [] ao redor das tags não ajudará muito na pesquisa do Gmail, apenas visualmente, pois, pelo que posso ver (por exemplo, veja https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character, a documentação vinculada não está mais lá, mas ainda é válida), o Gmail remove caracteres especiais ao pesquisar no assunto e em outros lugares. Tente pesquisar subject:("[support]") no Gmail, você obterá tudo com suporte no assunto, não apenas aqueles com colchetes. Isso é meio sem sentido do Google fazer isso, eles são uma empresa de pesquisa (bem, pesquisa e anúncios), mas não há nada que possamos fazer a respeito.

Também devemos ser capazes de adicionar facilmente X-Discourse-Tags e X-Discourse-Category ao mesmo tempo em MessageBuilder, pois já temos essas opções neste momento, e como você diz @mattdm, isso cobre bem os usuários resistentes à web:

Posso pegar isso se você quiser?

5 curtidas
21

Eu acabei de mesclar isso @mattdm:

Isso não ajuda muito com o Gmail, mas pelo menos deve ajudar os usuários de e-mail baseados em terminal para que eles possam filtrá-los com mais facilidade.

6 curtidas
22

Nota @mattdm, nós realmente tentamos, mas o Gmail é muito difícil. Ele remove muita coisa do texto ao tokenizar, suas mãos ficam bem atadas.

A única solução que consigo pensar é tornar os nomes das tags super feios nos e-mails:

“Este é um assunto de demonstração. [Temail, Tnotifications]” (prefixo T ou alguma outra sequência alfa que o Gmail “goste”)

Mas é uma solução bastante feia e não intuitiva.

3 curtidas
23

Obrigado Sam (e a todos!).

Agradeço todo o esforço dedicado a isso. No final, há apenas tanto que podemos lutar contra as escolhas inescrutáveis do Google.

Sim, sério. A única coisa que consigo pensar em fazer a mais seria adicionar uma opção por usuário:

Fazer com que as linhas de assunto das notificações por e-mail contenham nomes de tags em um formato super feio no qual o Gmail possa filtrar.

:-/

5 curtidas