Спасибо большое!
Вчера я реализовал первые два пользовательских соглашения (AC), и все тесты в стеке проходят успешно (хотя я еще не тестировал в рабочей среде), используя пользовательское поле в Topic и правило thread. Пока я не затрагивал поток транскрипции. Так что я добиваюсь хорошего прогресса в направлении возможности показать код хотя бы в черновике PR.
У меня также есть отдельный коммит для удаления неиспользуемого pstore_get из провайдера Slack. Поскольку это единственное использование pstore во всем стеке, хотите ли вы, чтобы я также удалил все pstore_* из app/initializers/discourse_chat.rb в этом коммите очистки?
Именно с этого я и начал, и это, безусловно, было бы проще!
Однако, по крайней мере, в моем случае (и я слышал это от людей в других компаниях, мы не уникальны), разные каналы имеют разные предпочтения относительно использования потоков. Есть каналы, которые предназначены для использования с потоками (потому что большинству людей интересны только некоторые темы), и каналы, которые категорически против потоков (потому что потоки скрывают важную информацию).
Я заметил два по сути не связанных между собой аспекта, определяющих это предпочтение:
- Членство: В каналах, где большинство участников десятилетиями активно использовали IRC, люди привыкли мысленно разграничивать перемешанные разговорные потоки в одном канале и не хотят переходить в потоки, чтобы увидеть важный контент. В то же время в каналах, где большинство участников привыкли к электронной почте, ожидают, что разговоры будут организованы в потоки, и они будут переходить в те разговоры, которые их интересуют.
- Цель: Каналы с бизнес-целью объявлений, как правило, агрессивно используют потоки, тогда как каналы с исследовательскими или коллаборативными целями часто намеренно не используют потоки, поскольку те скрывают информацию, если вы не заметите их и не перейдете внутрь.
Если вы хотите иметь общий синтаксис для опций правил, я бы подумал, что Rule можно расширить так, чтобы у него было значение :options, которое, как и :tags, является массивом. Мне кажется, что имеет смысл взять пример из командных оболочек, чтобы /discourse [watch|follow|mute] -something -here устанавливал :options в ['something', 'here'], где ведущий - обозначает опцию. Тогда это будет выглядеть так: /discourse watch my-category-slug #tagged-foo -threaded. Я не знаю, насколько больше работы это потребует по сравнению с тем, что я уже сделал. У вас есть сильные предпочтения в ту или иную сторону? Я вижу аргументы за и против: добавление еще одного значения в Rule усложняет написание чат-провайдера; добавление еще одного значения фильтра делает еще одну специфичную для Slack функцию (например, публикацию транскрипции), что усложняет интерфейс для пользователей, не использующих Slack. Конечно, я могу упускать что-то, что сделает это сложнее, чем я думаю; например, если slug категории может начинаться с -, это сразу создаст неоднозначность; оболочка использует --, чтобы означать «всё после этого не является аргументом», но, возможно, мы могли бы инвертировать это, так что -- будет означать «всё после этого является опцией». Если вы хотите, чтобы я изучил это, пожалуйста, дайте мне направление по синтаксису, который вы считаете подходящим для указания опций правил. Но просто добавить thread кажется мне проще, поэтому, пока нет конкретных указаний добавить общую функцию «options», я подожду с любыми изменениями в этом направлении.
[Редактирование: Переход от фильтра правила к опции определенно усложнит интерфейс, который должен будет получить общую поддержку общих опций, и это не кажется мне хорошим выбором. Поэтому, после рассмотрения интерфейса, я предпочитаю остаться с фильтром; я думаю, что это чище.]
Что касается потока транскрипции постов, спасибо за идею с HTML-комментарием. Для моего случая это меня никак не затруднит; я честно ожидаю быть основным пользователем, по крайней мере, на начальном этапе. Это приятный простой хак.
У меня есть отдельная идея, которую я не планирую включать в этот PR: было бы здорово иметь отображение от канала, из которого отправляется сообщение, к категории, в которой должен быть создан соответствующий пост в Discourse. Для этого, как мне кажется, транскрипт лучше изменить, добавив обертку или sidecar, в котором могли бы содержаться и категория, и ID Slack. Это выглядит как значительный объем обучения для меня, так как я все еще нахожусь на этапе «продвинутого гугления проблемы» при изучении Ruby on Rails. 
