Предложение функции: Автоматическое продление темы, когда тема письма совпадает с заголовком

Внести вклад Функция
1

В настоящее время, если два письма с одинаковой темой отправляются в заданную категорию Discourse, каждое из них создаёт новую тему, где тема письма становится заголовком темы. Это приводит к созданию нескольких тем с одинаковым заголовком, независимо от того, выбраны ли конфигурационные опции «Разрешать темы с идентичными, дублирующимися заголовками…», что может привести к множеству тем с одинаковым заголовком.

Здесь я прошу, чтобы такие сообщения, созданные по почте, автоматически объединялись в существующую тему, если они имеют одинаковую тему с этой темой, при условии, что опция «Разрешать темы с идентичными, дублирующимися заголовками, если категория отличается» снята (или путём добавления новой опции «Объединять сообщения, отправленные по почте, в существующую тему, если её тема совпадает с заголовком темы»). Это позволило бы избежать дублирования заголовков в категории, а также допускало бы накопление нескольких писем в одной теме, если они имеют одинаковую тему (намеренно или случайно).

На практике это возникает у нас, когда у нас есть скрипты, которые создают сообщения, предназначенные для связи друг с другом в рамках одной темы, например: «такая-то конфигурация тестирования не удалась» или «кто-то упомянул xyz на Reddit». Было бы идеально, если бы все письма с такой темой группировались в одной теме, а не создавалась новая тема для каждого письма с идентичным заголовком. Это также позволило бы кому-то добавить новое сообщение в существующую тему по электронной почте, не обязательно отвечая на письмо с уведомлением о предыдущем сообщении в этой теме, для тех, кто по тем или иным причинам должен писать по почте, а не через веб-интерфейс.

Я считаю, что потенциальные недостатки в случаях, когда люди случайно отправляют письма, чья тема совпадает с существующей темой, о которой они не знали, минимальны. В основном потому, что я предполагаю, что если их тема совпадает с заголовком существующей темы, это связано с похожостью контента, поэтому не кажется большой проблемой расширить существующую тему, а не создавать новую с дублирующимся заголовком. Более того, администратор сайта всегда может включить опцию «Разрешать темы с одинаковыми заголовками…», если он хочет, чтобы каждое новое письмо создавало новую тему.

Эта функция была бы невероятно полезна для нашего сайта Discourse, и, как я предполагаю, вероятно, полезна и для других. Спасибо за внимание и за всю отличную инженерную работу, которая, очевидно, была проделана в Discourse.

Topics with same title, generated from mail
2

Я думаю, что это очень специфично для конкретного сообщества; по вашему собственному признанию, непреднамеренные совпадения всё же будут возникать. В чём ценность наличия меньшего количества гораздо более длинных тем?

Для таких сообществ, как Meta, это означало бы, что любой пользователь, отправивший письмо с темой «проблемы с настройкой Mailgun», будет продолжать получать уведомления об обновлениях спустя месяцы или даже годы после решения своей проблемы. Это звучит непрактично.

Цель — избегать дублирования заголовков, что текущий параметр обеспечивает для тем, созданных на сайте, поскольку пользователю можно предоставить обратную связь в момент создания темы. Однако этот параметр не соблюдается для пользователей, отправляющих письма по электронной почте, поскольку такой возможности нет.

3

Спасибо, что откликнулись на это, @Stephen.

Я думаю, это очень специфично для конкретного сообщества

Я согласен. Вот почему я предлагаю управлять этим через флажок в настройках (либо переиспользуя один из существующих, касающихся запрета дублирующихся заголовков, либо добавив новый).

В чём ценность наличия меньшего количества гораздо более длинных тем?

Для контекста: на нашем сайте Discourse есть категория «Уведомления», подкатегории которой получают письма, отправляемые скриптами при наступлении определённых событий (например, сбои тестирования, новые созданные задачи, новые вопросы на Stack Overflow, новые упоминания нашего проекта на дискуссионных площадках и т. д.). Эти категории предназначены для того, чтобы участники сообщества могли отслеживать и обсуждать определённые типы событий, которые их интересуют.

В некоторых случаях письма, генерируемые нашими скриптами, имеют предсказуемые, детерминированные темы по дизайну, например «linux64 testing». Например, если 15 августа у нас возник новый сбой в тестировании linux64, это порождает письмо. Если 16 августа добавляются новые сбои, генерируется второе письмо с тем же заголовком. Затем, если 17 августа все сбои устранены, генерируется третье письмо с тем же заголовком, указывающее на решение. Далее, если 31 августа появляются новые сбои, создаётся четвёртое письмо с тем же заголовком, и пятое — при их устранении.

При текущем поведении сайта каждое такое письмо создаёт совершенно новую тему с названием «linux64 testing» без какой-либо связи или отношения между ними, что затрудняет для людей корреляцию событий или решение, какую из пяти тем использовать для последующего обсуждения сбоев. В то время как мы хотели бы, чтобы все пять писем (и любые обсуждения пользователей, возникшие по их поводу) отображались как посты в рамках одной темы, чтобы разработчик мог увидеть все сбои тестирования в данной конфигурации в одной теме, организованные хронологически.

Другое последствие текущего поведения Discourse заключается в том, что человек, получающий уведомления по электронной почте для данной категории или темы, видит в своём почтовом ящике пять несвязанных потоков с названием «linux64 testing». В то время как если бы Discourse объединял их в одну тему, этот человек видел бы все посты «linux64 testing», связанные как единый поток в своём почтовом клиенте, что значительно упрощает навигацию и делает процесс более похожим на традиционное общение.

Мы запускаем несколько десятков конфигураций тестирования каждую ночь, и каждая из них имеет уникальный заголовок при возникновении сбоев, поэтому текущая ситуация приводит к чему-то вроде запутанного хаоса, в котором трудно ориентироваться: отдельная поверхностная тема на каждое письмо, все они перемешаны в хронологическом порядке. В то время как наша идеальная модель — чтобы категория «Notifications.Tests» показывала одну тему на конфигурацию, в которой хранятся все посты (сгенерированные людьми или скриптами) об этой конфигурации, упорядоченные хронологически и определяемые этим уникальным заголовком.

[Эта категория тестирования в настоящее время не видна публично на нашем сайте, @Stephen, но если вы хотите увидеть, как это выглядит, и прочувствовать проблему на себе, я с радостью временно предоставлю вам доступ для чтения… просто дайте мне знать.]

Для сообществ, подобных meta, это означало бы, что любой пользователь, написавший по электронной почте с запросом «проблемы с настройкой Mailgun», будет продолжать получать уведомления об обновлениях через месяцы или годы после решения своей проблемы.

Я согласен, что такой выбор может быть не столь разумным для такого большого и долгоживущего сообщества, как meta, у которого нет необходимости агрегировать посты, генерируемые письмами, в одну тему, как это делаем мы. Поэтому, вероятно, вы не захотели бы активировать такую функцию, если бы она существовала. (И возможно, со временем и наш сайт тоже не захочет её использовать по тем же причинам; в таком случае, я считаю, идеальным было бы возможность применять флажок на уровне каждой категории, но я не хотел просить слишком многого, поскольку полагаю, что на данный момент достаточно одного общесайтового параметра).

Тем не менее, даже если такой сайт, как наш, активировал бы эту функцию, и автор оригинального поста темы «проблемы с настройкой Mailgun» был бы раздражён последующими постами с тем же заголовком, предположительно он мог бы отписаться от темы, чтобы перестать получать обновления, если/когда кто-то другой использует тот же заголовок (или просто добавит ещё один пост в данную тему через веб-интерфейс)?

[Тем не менее, я ожидаю, что большинство пользователей будут публиковать посты через веб-сайт, поэтому представляю, что эта функция окажет большее влияние на посты, генерируемые скриптами, чем на те, что создаются людьми]