Мне очень нравится сама идея медленного режима, но он не совсем решает главную причину перепалок на нашем Discourse:
Кто-то заходит «в горячем» состоянии — часто новичок или представитель другого сообщества — и выкладывает список претензий.
Многие действующие участники отвечают, общаясь с автором или обращаясь к нему, с разными мотивами (но синдром «Кто-то не прав в интернете» “I think someone is wrong on the internet” стоит на первом месте).
Автор хочет ответить каждому.
Даже в лучших дискуссиях всё быстро выходит из-под контроля.
Медленный режим здесь не помогает, потому что проблема заключается во множестве участников, отвечающих одному человеку. Часто это лишь ещё больше отдаляет нового участника, ведь именно он ощущает на себе все ограничения: пока у него тикает таймер задержки, многие могут ему отвечать, а ответить он может только одним сообщением.
Один инструмент, которого мне не хватает в арсенале для подобных ситуаций, — это замедление поднятия тем. В списках по умолчанию (как «Последние», так и «Лучшие») приоритет отдаётся таким «горячим» темам. Я бы хотел иметь возможность ограничивать поднятие темы до одного раза в 12 часов или подобный интервал. Тогда это не будет полным удалением из списка, но станет значительным снижением видимости, что может помочь сократить приток новых участников в дискуссию (если только они не ищут её специально, что вполне допустимо).
Мотивированный пользователь мог бы написать один ответ и тем самым поднять множество других постов, верно? … Это всё ещё было бы возможно в режиме медленной отправки.
Но я согласен, что уменьшение количества «подниманий» темы было бы также полезно в режиме медленной отправки.
Абсолютно верно, но такие монструозные ответы, адресованные множеству сообщений, лишь усложняют управление темой. Разделение становится невозможным, и они склонны ещё больше настраивать автора против себя (или, по крайней мере, создают видимость раздражения просто из-за огромного массива текста).
На самом деле это ещё одно непредвиденное последствие режима «медленный чат», которое мы наблюдали на форуме Julia — платном и довольно активном хостинге: режим замедления включается, и некоторые пользователи начинают редактировать свои посты вместо того, чтобы писать новые. Похожая проблема возникает при установке для проблемного пользователя уровня TL0: он не может создавать новые посты, но всё ещё может редактировать старые, поэтому делает именно это. Это особенно плохо, если он писал провокационные сообщения, на которые люди отвечали, а затем он их редактирует, из-за чего ответы выглядят неуместными.
Но да, я полностью поддерживаю предложение @mbauman — возможность предотвратить частое поднятие горячих тем была бы очень полезна для снижения накала страстей.
Помимо предотвращения поднятия горячей темы, хорошей идеей может быть задержка уведомлений. Это частично решает проблему, когда кто-то отвечает нескольким пользователям или упоминает их.
Один из приёмов, который можно применить уже сегодня, — сделать такие темы скрытыми. Мы планируем добавить таймеры для автоматического восстановления видимости, но пока это можно сделать вручную.
Раньше уже обсуждалась идея «похоронить» тему, и мы тоже об этом думали.
[quote=“mbauman, пост:1, тема:200080”]
Один инструмент, которого мне не хватает в арсенале для подобных ситуаций, — это замедление поднимания тем в топе. Списки по умолчанию (как «Свежее», так и «Лучшее») отдают приоритет таким «горячим» темам. Мне бы хотелось иметь возможность ограничивать поднятие тем, например, до одного раза в 12 часов или что-то в этом роде. Тогда это не будет полным снятием с публикации, но станет значительным снижением видимости, что могло бы помочь ограничить приток новых участников к обсуждению (если только они не ищут тему намеренно, что вполне нормально).[/quote]
Я не совсем понимаю, что вы предлагаете. Можете показать макет интерфейса, как это будет работать: что увидит пользователь, что увидит сотрудник?
[quote=“StefanKarpinski, пост:4, тема:200080”]
Когда включается медленный режим, некоторые люди начинают редактировать свои посты вместо того, чтобы писать новые.[/quote]
Именно поэтому в медленном режиме по умолчанию ограничено редактирование. Вы можете отключить эти ограничения, если доверяете своему сообществу, что они так не будут делать.
И учтите то, что сказал @sam. Сделайте тему невидимой в списках. Пожалуйста, используйте полностью существующие инструменты вашего арсенала, прежде чем предлагать новые.
Основная идея довольно проста: я бы назвал это что-то вроде «Ограничить поднятие тем…» в меню администратора темы (вероятно, рядом с пунктом « Сбросить дату поднятия»). Это должно открывать модальное окно, предлагающее ввести временной период. Текст мог бы выглядеть примерно так: «Ограничить частоту появления этой темы вверху списков «Последнее» и других категорий до одного раза каждые X часов», со значением по умолчанию, например, 8 часов.
У меня нет четкого мнения о том, как это должно быть реализовано; это может быть состояние (отслеживать последний пост, изменивший время обновления темы, и обновлять его только если время нового поста превышает X часов в будущем) или без состояния (всегда устанавливать время обновления темы как ближайшее вниз кратное X часов от начала эпохи Unix или от первого поста). Или что-то еще, как угодно.
Что касается отображения пользователю, я не на 100% уверен, что это должно сообщаться им, но это могло бы выглядеть как элемент «не включенного в список» поста, просто гласящий: «эта тема будет появляться вверху списков тем только один раз каждые X часов».
Что касается других инструментов, мы иногда используем исключение тем из списков, но здесь речь идет о конфликтных новых пользователях — часто таких людях, которые могут крайне болезненно воспринять малейший намек на цензуру. И я действительно не хочу цензурировать/скрывать/удалять что-либо. Вся суть в более мягкой интервенции, которая, надеюсь, с меньшей вероятностью сама по себе вызовет дополнительное раздражение, но, возможно, поможет немного снизить накал страстей.
Это отчасти вдохновлено тем, как Hacker News наказывает темы, у которых значительно больше комментариев, чем голосов «за».
Что вы думаете об этом, @sam@eviltrout? Мы могли бы использовать здесь целое число, обозначающее время, где 0 означает «никогда не позволять поднимать тему», а значения от 1 до 6000 — «разрешить одно поднятие каждые {x} минут» или что-то в этом роде.
Это интересная идея — что-то вроде дребезга для ударов.
Похоже на инструмент для работы с мощностью, но я вижу, что это может быть полезно. Не думаю, что это легко реализовать — вероятно, потребует усилий среднего уровня.
Думаю, в некоторых сценариях полезно предотвратить излишнее обсуждение темы с самого начала, если модерация заметит это вовремя. Особенно в случаях с большим количеством пользователей.
Если тема уже «нагрета» и обсуждение самоподдерживается, режим «медленный», вероятно, сработает лучше, так как уведомления, которые пользователи получают от взаимодействий в теме, (скорее всего) будут поддерживать активность.
Я изучил исходный код и, помимо изменения моделей, достаточно ли изменить bypass_bump?, чтобы предотвратить поднятие тем?
Может быть, добавить поле в Topic, например min_seconds_between_bumps, и ещё одно условие в bypass_bump?:
Не уверен насчёт значения 0, указывающего, что тему вообще нельзя поднимать. Это может запутать некоторых пользователей. Если реализовать так, то, на мой взгляд, для лучшего UX веб-приложение не должно напрямую показывать ноль пользователю.
Если я правильно понимаю, решение о том, поднимать ли тему, принимается в момент публикации ответа, но если после периода «без поднятия» не последует новых ответов, тема никогда не будет поднята.
Это желаемое поведение или тема должна всегда подниматься в конце периода «без поднятия», если в течение этого периода был опубликован ответ? Если она должна всегда подниматься, то должна ли она подниматься до «текущего времени» или до времени последнего ответа?
Да, в этом подходе решение принимается при публикации ответа, и если новых ответов не последует, тема больше никогда не будет поднята. Если я прав — а я не эксперт в исходном коде Discourse, так что не уверен, — это был бы самый простой способ реализации.
Другой возможный вариант — поднятие темы после периода охлаждения — вероятно, потребует больше работы, как и сказал @eviltrout, поскольку приложению нужно будет хранить информацию о следующем ожидаемом поднятии и иметь какой-либо планировщик или задачу Sidekiq для периодического выполнения отложенных поднятий.
Оба подхода допустимы, и если эта функция когда-либо будет реализована, я не знаю, какой из них будет выбран.
Лично мне неважно, если проблемная тема больше никогда не будет поднята при отсутствии новых ответов. Но это лишь моё мнение.
У темы есть настройка «можно поднимать только один раз в {x} минут», где количество минут — это регулируемый параметр, варьирующийся от нуля (по умолчанию, можно поднимать столько раз, сколько есть ответов) до ~10 000 (можно поднимать только раз в неделю). Допустим, кто-то указал 60 минут: тогда тему можно поднимать максимум один раз в 60 минут.
При публикации ответа проверяется дата последнего поднятия темы:
если дата последнего поднятия была более 60 минут назад, разрешить поднятие темы этим новым ответом.
если дата последнего поднятия была менее 60 минут назад, не поднимать тему при публикации этого нового ответа.
Да, это кажется простым и реализуемым… давайте добавим это в следующий релиз @sam@eviltrout?
Могло бы значение -1 (нельзя поднимать бесконечно) быть полезным? Мне кажется, я склоняюсь к «нет»: такие темы будет сложно найти позже (без дополнительных усилий), а если администратор действительно хочет, чтобы тема никогда больше не поднималась, то, вероятно, имеет смысл просто закрыть её.
На самом деле я считаю, что максимальное время должно быть настраиваемым параметром на странице администратора. Что-то вроде max_slowbump_time или подобное.
Также, раз уж мы об этом. Возможно ли применить медленные поднятия на уровне категории?
Реализовывалась ли когда-нибудь подобная функция? У нас есть другая ветка обсуждения, которая побудила @mbauman изначально запросить эту возможность, и если эта функция теперь существует, было бы здорово иметь возможность её использовать.