Muito obrigado!
Ontem à noite, implementei e tenho testes passando em toda a pilha (embora ainda não tenha testado em produção) meus dois primeiros ACs, mas ainda não o fluxo de transcrição, usando um campo personalizado em Topic e uma regra thread. Então, estou fazendo bom progresso para conseguir mostrar código em pelo menos um PR de rascunho.
Também tenho um commit separado para remover o pstore_get não utilizado do provedor do Slack. Como esse é o único uso de pstore em toda a pilha, você gostaria que eu também removesse todos os pstore_* de app/initializers/discourse_chat.rb nesse commit de limpeza?
É exatamente onde eu comecei, e certamente teria sido mais fácil!
No entanto, pelo menos para o meu caso de uso (e já ouvi isso de pessoas em outras empresas, não somos únicos), diferentes canais têm preferências diferentes sobre se threads devem ser usadas. Existem canais que são destinados a serem usados com threads (porque a maioria das pessoas se importa apenas com alguns tópicos) e canais que são fortemente contra threads (porque threads escondem informações importantes).
Vi dois aspectos essencialmente não relacionados impulsionando essa preferência:
- Membros: Canais com a maioria dos membros usando IRC ativamente há décadas estão acostumados a desambiguar mentalmente threads de conversas intercaladas em um único canal e não querem clicar em threads para ver conteúdo importante, enquanto canais com a maioria dos membros vindo do email esperam que as conversas sejam threadizadas e que se clique nas conversas que lhes interessam.
- Propósito: Canais com finalidade de anúncio tendem a ser fortemente threadizados, mas canais com fins de pesquisa ou colaboração muitas vezes intencionalmente não são threadizados porque threads escondem informações a menos que você as note e clique nelas.
Se você quiser ter alguma sintaxe comum para opções de regra, eu pensaria que Rule poderia ser expandida de modo geral para ter um valor :options que, como :tags, seja um array. Suponho que faria sentido pegar uma página dos shells de linha de comando, de modo que /discourse [watch|follow|mute] -algo -aqui defina :options para ['algo', 'aqui'] — reservando um - inicial para introduzir uma opção. Então seria /discourse watch minha-categoria-slug #tagged-foo -threaded. Não sei quanto mais trabalho isso seria em comparação com o que já fiz. Você tem sentimentos fortes de um lado ou do outro aqui? Vejo argumentos para ambos os lados: adicionar outro valor a Rule torna mais complicado escrever um provedor de chat; adicionar outro valor de filtro torna outro recurso específico do Slack (como postar uma transcrição) que torna a interface mais complicada para usuários que não são do Slack. Claro que posso estar perdendo algo que tornaria mais difícil do que penso; por exemplo, se um slug de categoria pudesse começar com - e isso se tornaria ambíguo; o shell usa -- para significar “tudo após isso não é um argumento”, mas talvez pudéssemos inverter para -- significar “tudo após isso é uma opção.” Se você quiser que eu pesquise isso, por favor, me dê alguma direção sobre a sintaxe que você consideraria apropriada para especificar opções de regra. Mas apenas adicionar thread parece mais simples para mim, então, na ausência de uma direção específica para adicionar um recurso geral de “opções”, vou aguardar para fazer qualquer mudança nessa direção.
[Edição: Mudar de um filtro de regra para uma opção definitivamente complicaria a UI, que teria que crescer para suporte geral a opções gerais, e isso não parece uma ótima escolha para mim. Então, agora, tendo olhado para a UI, prefiro manter o filtro; acho que é mais limpo.]
Para o fluxo de transcrição de post, obrigado pela ideia do comentário HTML. Para o meu caso de uso, não vai me prejudicar de forma alguma; honestamente, espero ser o usuário principal, pelo menos inicialmente. Esse é um hack simples e legal.
Tenho uma ideia separada, não para embutir neste PR, de que seria bom ter um mapeamento do canal para a mensagem sendo postada até a categoria na qual o post resultante do Discourse deve ser feito. Para que isso aconteça, acho que a transcrição mudaria melhor para ter um envelope ou sidecar, momento em que o envelope ou sidecar poderia ter tanto a categoria quanto o ID do Slack. Isso parece uma quantidade substancial de aprendizado para mim, já que ainda estou na fase de “pesquisa avançada do problema” aprendendo Ruby on Rails. 
