¡Muchas gracias!
Anoche implementé y tengo pruebas exitosas en toda la pila (aunque aún no he probado en vivo) mis primeros dos CAs, pero aún no el flujo de transcripción, utilizando un campo personalizado en Topic y una regla thread. Así que estoy avanzando bien hacia la capacidad de mostrar código en al menos un PR de borrador.
También tengo un commit separado para eliminar el pstore_get sin uso del proveedor de Slack. Dado que ese es el único uso de pstore en toda la pila, ¿te gustaría que también elimine todos los pstore_* de app/initializers/discourse_chat.rb en ese commit de limpieza?
Ese fue exactamente mi punto de partida, y sin duda habría sido más fácil.
Sin embargo, al menos para mi caso de uso (y he escuchado esto de personas en otras empresas, no somos únicos), diferentes canales tienen diferentes preferencias sobre si se deben usar hilos. Hay canales que están destinados a usarse con hilos (porque la mayoría de las personas solo se preocupan por algunos temas) y canales que son muy anticlínicos (porque los hilos ocultan información importante).
He visto dos aspectos esencialmente no relacionados que impulsan esta preferencia:
- Membresía: Los canales donde la mayoría de los miembros han usado IRC activamente durante décadas están acostumbrados a desambiguar mentalmente hilos conversacionales entremezclados en un solo canal y no quieren hacer clic en los hilos para ver contenido importante, mientras que los canales donde la mayoría de los miembros han vivido en correo electrónico esperan que las conversaciones estén en hilos y hacer clic en las conversaciones que les importan.
- Propósito: Los canales con un propósito comercial de anuncios tienden a estar fuertemente hilados, pero los canales con propósitos de investigación o colaboración a menudo intencionalmente no están hilados porque los hilos ocultan información a menos que te des cuenta y hagas clic en ellos.
Si deseas tener alguna sintaxis común para las opciones de regla, creo que Rule podría expandirse en general para que tenga un valor :options que, como :tags, sea un array. Supongo que podría tener sentido tomar una página de las shells de línea de comandos, de modo que /discourse [watch|follow|mute] -something -here establezca :options en ['something', 'here'] — reservando un - inicial para introducir una opción. Entonces sería /discourse watch my-category-slug #tagged-foo -threaded. No sé cuánto más trabajo sería eso sobre lo que ya hice. ¿Tienes sentimientos fuertes en un sentido u otro aquí? Puedo ver argumentos para ambos lados: agregar otro valor a Rule lo hace más complicado de escribir para un proveedor de chat; agregar otro valor de filtro hace que otra característica específica de Slack (como publicar una transcripción) que hace que la interfaz sea más complicada para usuarios que no son de Slack. Por supuesto, podría estar pasando por alto algo que lo haría más difícil de lo que creo; por ejemplo, si un slug de categoría podría comenzar con - y de repente se vuelve ambiguo; la shell usa -- para significar “todo lo que sigue no es un argumento” pero quizás podríamos invertirlo para que -- signifique “todo lo que sigue es una opción.” Si deseas que investigue esto, por favor dame alguna dirección sobre la sintaxis que considerarías apropiada para especificar las opciones de regla. Pero simplemente agregar thread me parece más simple, así que, sin una dirección específica para agregar una característica general de “opciones”, esperaré para hacer cualquier cambio en esa dirección.
[Edición: Cambiar de un filtro de regla a una opción definitivamente complicaría la interfaz de usuario, que tendría que crecer para admitir opciones generales en general, y eso no me parece una gran elección. Así que ahora, habiendo visto la interfaz de usuario, preferiría mantenerme con el filtro; creo que es más limpio.]
Para el flujo de transcripción de publicaciones, gracias por la idea del comentario HTML. Para mi caso de uso no me va a hacer daño; honestamente espero ser el usuario principal de todos modos, al menos inicialmente. Ese es un buen truco simple.
Tengo una idea separada, no para incrustar en este PR, de que sería bueno tener una mapeo desde el canal para el mensaje que se está publicando hacia la categoría en la que se debe hacer la publicación resultante en Discourse. Para que eso suceda, creo que la transcripción cambiaría mejor para tener un sobre o un sidecar, momento en el cual el sobre o el sidecar podrían tener tanto la categoría como el ID de Slack. Eso parece una cantidad sustancial de aprendizaje para mí, ya que todavía estoy en la etapa de “búsqueda avanzada del problema” aprendiendo Ruby on Rails. 
