Merci beaucoup !
Hier soir, j’ai implémenté mes deux premiers critères d’acceptation (AC) avec des tests réussis dans toute la stack (bien que je n’aie pas encore testé en production), en utilisant un champ personnalisé sur Topic et une règle thread. Je ne me suis pas encore penché sur le flux de transcription. Donc, je fais de bons progrès vers la possibilité d’afficher du code dans au moins une PR de brouillon.
J’ai également un commit séparé pour supprimer pstore_get inutilisé du fournisseur Slack. Puisque c’est la seule utilisation de pstore dans toute la stack, souhaitez-vous que je supprime également toutes les références pstore_* dans app/initializers/discourse_chat.rb lors de ce commit de nettoyage ?
C’est exactement là que j’ai commencé, et cela aurait certainement été plus simple !
Cependant, du moins pour mon cas d’utilisation (et j’ai entendu cela de la part de personnes dans d’autres entreprises, nous ne sommes pas uniques), différents canaux ont des préférences différentes concernant l’utilisation des fils de discussion. Il y a des canaux destinés à être utilisés avec des fils de discussion (car la plupart des gens ne s’intéressent qu’à certains sujets) et des canaux qui sont très fortement opposés aux fils de discussion (car ils enfouissent les informations importantes).
J’ai observé deux aspects essentiellement indépendants qui influencent cette préférence :
- Membres : Les canaux dont la majorité des membres utilisent IRC depuis des décennies sont habitués à dissocier mentalement les fils de conversation entremêlés dans un seul canal et ne veulent pas cliquer dans les fils pour voir le contenu important, tandis que les canaux dont la majorité des membres ont grandi avec le courrier électronique s’attendent à ce que les conversations soient threadées et à cliquer sur les conversations qui les intéressent.
- Objectif : Les canaux à vocation d’annonce ont tendance à être fortement threadés, mais les canaux à vocation de recherche ou de collaboration sont souvent intentionnellement non threadés, car les fils de discussion cachent les informations à moins de les remarquer et d’y cliquer.
Si vous souhaitez une syntaxe commune pour les options de règle, je pense que Rule pourrait être généralisé pour inclure une valeur :options, qui, comme :tags, est un tableau. Je suppose qu’il pourrait être logique de s’inspirer des shells en ligne de commande, de sorte que /discourse [watch|follow|mute] -something -here définisse :options à ['something', 'here'] — en réservant le préfixe - pour introduire une option. Ainsi, cela donnerait /discourse watch ma-catégorie-slug #tagged-foo -threaded. Je ne sais pas combien de travail supplémentaire cela représenterait par rapport à ce que j’ai déjà fait. Avez-vous des avis tranchés dans un sens ou dans l’autre ? Je vois des arguments des deux côtés : ajouter une autre valeur à Rule complique l’écriture d’un fournisseur de chat ; ajouter une autre valeur de filtre rend une autre fonctionnalité spécifique à Slack (comme la publication d’une transcription) qui complexifie l’interface pour les utilisateurs non-Slack. Bien sûr, il se peut que j’aie manqué quelque chose qui rendrait cela plus difficile que je ne le pense ; par exemple, si un slug de catégorie pouvait commencer par -, cela deviendrait soudainement ambigu ; le shell utilise -- pour signifier « tout ce qui suit n’est pas un argument », mais nous pourrions peut-être l’inverser pour que -- signifie « tout ce qui suit est une option ». Si vous souhaitez que j’explore cette piste, veuillez me donner des indications sur la syntaxe que vous jugeriez appropriée pour spécifier les options de règle. Mais ajouter simplement thread me semble plus simple, donc en l’absence d’instructions spécifiques pour ajouter une fonctionnalité générale « options », j’attendrai de faire tout changement dans cette direction.
[Édité : Passer d’un filtre de règle à une option compliquerait certainement l’interface utilisateur, qui devrait évoluer pour prendre en charge les options générales, et cela ne me semble pas être un bon choix. Maintenant, après avoir examiné l’interface utilisateur, je préfère rester sur le filtre ; je pense que c’est plus clair.]
Pour le flux de transcription des publications, merci pour l’idée du commentaire HTML. Pour mon cas d’utilisation, cela ne me posera aucun problème ; je m’attends honnêtement à être l’utilisateur principal, du moins initialement. C’est un petit hack simple et efficace.
J’ai une autre idée, à ne pas intégrer dans cette PR : il serait agréable d’avoir une correspondance entre le canal pour le message en cours de publication et la catégorie dans laquelle la publication Discourse résultante doit être créée. Pour que cela se produise, je pense que la transcription devrait mieux changer pour inclure une enveloppe ou un sidecar, auquel cas l’enveloppe ou le sidecar pourrait contenir à la fois la catégorie et l’ID Slack. Cela représente une quantité considérable d’apprentissage pour moi, car je suis encore dans la phase de « recherche avancée du problème sur Google » pour apprendre Ruby on Rails. 
