Короткий вопрос по поводу вышеизложенного. Как насчет автоматически закрытых тем с решением? Логично, что их нужно показывать, так как у них есть решение, но, если я правильно понял, сейчас они автоматически становятся менее заметными.
15 лайков
Можно ли переключать это через настройку сайта? В некоторых случаях тема может быть и закрыта, и отмечена как решённая. Напротив, некоторые пользователи могут даже ожидать, что такие темы будут выше в результатах.
[quote=“Sam Saffron, post:1, topic:254158, username:sam”]
Как вам изменения (нейтрально/лучше/хуже)?[/quote]
Мне очень приятно видеть, что поиску уделяют внимание. Возможность искать по конкретной категории уже является большим плюсом для нашего использования.
Единственное, что я хотел бы видеть с некоторым улучшением, — это обработка распространённых опечаток. Некоторые поисковые системы избаловали меня до такой степени, что я лениво долблю клавиши, пока в строке поиска не окажется смесь букв, лишь отдалённо напоминающих исходное слово 
. Я не ожидаю, что это будет точно совпадать, но улучшения в этой области стали бы большим шагом вперёд.
9 лайков
Смелое мнение! Я думаю, что лучше сохранить единообразие (то есть не вводить опции для каждого сайта), и:
- Увеличить приоритет закрытых тем, которые решены (до более высокого, чем у открытых тем).
- Добавить возможность настройки таймера (в идеале — для каждой категории и/или тега) для автоматического архивирования закрытых тем.
- В архивированных темах повышать приоритет тем с решениями — но не настолько, чтобы они отображались выше неархивированных тем.
Отказ от ответственности: да, я действительно хочу эту функцию автоматического архивирования для своего собственного сайта! Но я считаю, что она имеет смысл в целом. Всё, что уже ответили, но, вероятно, больше не актуально, должно быть убрано. А если вы этого не хотите (ваши решённые вопросы всегда актуальны), просто не включайте архиватор.
8 лайков
Почему? Потому что это упрощает разработку? Или потому что это облегчает жизнь пользователям, когда они переходят между разными форумами на движке Discourse? Или есть какая-то другая причина?
Первая причина не является причиной вовсе — пока рабочая нагрузка разумна, а задача выполнима в рамках этой реальности. Вторая причина — веская аргументация для Microsoft или Apple, которые не хотят слишком сильно напрягаться ради клиентов, но в остальных случаях — как администратор и создатель контента я хочу служить своим пользователям, а не стараться сделать всё похожим на то, что есть здесь, там или где-то ещё 
Так что — третий вариант является наиболее интересным.
4 лайка
И то, и другое. А также потому, что это снижает сложность для администраторов. Вместо множества дополнительных опций (и риска даже не заметить, что существует настройка для выполнения нужного действия), лучше отойти в сторону и найти общий паттерн, чтобы желаемое поведение просто работало в большинстве случаев.
7 лайков
Это, безусловно, сильный аргумент.
Но могли бы мы использовать другое, но при этом привычное решение: скрытые настройки?
Я вижу здесь две разные стратегии:
- Должны ли администраторы иметь полную свободу в настройке важных аспектов, например результатов поиска, поскольку потребности сообщества различаются и не зависят от платформы (это вопрос разработки/кодирования)?
- Должны ли администраторы рассматриваться как обычные пользователи, чтобы поддерживать порядок и чистоту с точки зрения UX, а CDCK сам решал, что, где и почему?
Смотря на Support, у обоих подходов есть свои плюсы и минусы Но всё же — первый путь больше соответствует миру открытого исходного кода, тогда как второй — это подход Apple.
Больше опций порождает больше вопросов и проблем со стороны не слишком опытных администраторов, вроде меня. Больше опций может дать лучшие результаты для пользователей и посетителей. Так что же?
Для меня вопрос очень прост: я хочу максимально мощный поиск, и если закрытие темы снижает её рейтинг в результатах поиска, я больше не закрываю темы или делаю это крайне редко. Простой выбор, но тогда мне приходится действовать из-за ограничений программного обеспечения, а не из-за потребностей сообщества.
Так что — стратегии и тактика — это разные вещи
4 лайка
У нас уже есть множество подобных настроек: например, приоритет поиска по категориям, который может настроить любой администратор.
Я точно не против добавить ещё несколько настроек, влияющих на то, как темы с пометками «архивировано/закрыто/решено» получают бонус (или штраф) в результатах поиска.
Это немного отвлекает от основной темы. Предлагаю вынести это в отдельную тему с чётким предложением о том, какие настройки имели бы смысл.
8 лайков
Хотелось бы обсудить возможные следующие шаги по внесению изменений, учитывая проявленный на данный момент интерес.
В настоящее время логика выглядит следующим образом:
Как отметил @sam:
обратите внимание на этот крайний случай!
На meta… учитывая шум в канале Support, мы склонны понижать его приоритет… после понижения приоритета бонус за закрытие в ранжировании перестает действовать…
Таким образом, ещё один аспект для рассмотрения — как это взаимодействует с весами категорий.
Мне кажется, итеративный подход мог бы быть следующим:
- Просто добавить случай для решённых тем:
WHEN topics.solved then 1.1. - Изменить веса для архивированных, закрытых и решённых тем, сделав их множителями веса категории и друг друга.
- Сделать множители весов для архивированных, закрытых и решённых тем настраиваемыми через параметры сайта.
Возможно, имеет смысл сделать всё это сразу. А может, сначала реализовать пункты (1) и (2), а настройку отложить на потом. Что вы думаете, @sam?
3 лайка
Использование множителей, похоже, в целом хороший подход, но, мне кажется, им трудно выразить то, что я предлагал выше.
закрыто не решено < открыто не решено < открыто решено < закрыто решено
Закрытие должно повышать приоритет для решённых вопросов, но понижать его для нерешённых.
Закрытые вопросы без решения практически бесполезны — у кого-то возникла эта проблема, но ответа здесь нет, и вы не можете его дать. Закрытые вопросы с решениями, напротив, — золото. Они не просто решены, а решены окончательно.
4 лайка
Хорошо, и кроме того, вы ранее упоминали также архивированные темы:
Правильно ли я понимаю, что вы предпочитаете ранжировать элементы следующим образом?
(от высшего к низшему)
- закрытые, решённые
- открытые, решённые
- открытые, нерешённые
- закрытые, нерешённые
- архивированные, решённые
- архивированные, нерешённые
(А затем каким-то образом добавить многоуровневую сложность ранжирования по категориям)
2 лайка
Да, в целом, хотя порядок архивных постов, вероятно, не имеет значения:
Архивные посты с решениями, скорее всего, неактуальны, но могут представлять исторический интерес. Архивные посты без решений — по сути то же самое: если вы ищете в архиве, то, вероятно, вас интересует история, поэтому статус решения является информацией, но если важно, какой именно пост, вы должны явно указать это в своём запросе.
2 лайка
Используете ли вы сами категоризацию с весами? Если да, то как вы считаете: этот вес должен перевешивать текущие весовые коэффициенты, основанные на штатах, или они должны быть перемножены?
1 лайк
Я думаю, что переключатель для поиска в конкретной категории достаточно хорош и позволит исключить лишние веса при поиске (ведь люди ищут решения, а не категории или предлагаемые темы/категории).
Мое скромное мнение: я полностью согласен с тем, что вы здесь делаете 
2 лайка
Да, безусловно используем. У нас есть некоторые категории «рабочего процесса», которые должны появляться только по запросу, и другие — объявления и новости, которые более важны.
Я придумываю это прямо сейчас, поэтому оставляю за собой право изменить своё мнение в будущем, но моё ощущение таково: я хочу, чтобы веса категорий переопределяли все веса статуса темы, кроме архивированных. Я думаю о случае с новостями. Они должны появляться высоко в результатах, пока свежи, но не появляться вовсе после определённого периода времени. И архивирование постов может быть способом каждого сайта определять, что означает «определённый период времени» в данном контексте.[1]
Альтернативный, возможно, более простой вариант: просто позволить весам категорий переопределять всё, а затем ввести опцию для каждой категории для предпочтения свежих постов; если она включена, применяется множитель, который уменьшается со временем (например, от 2x до 0.5x).
А ещё есть запрос на автоматическое архивирование по таймеру, но это уже детали, детали! ↩︎
2 лайка
Хорошо, из того, что я слышу, следует, что веса категорий должны иметь приоритет.
Я считаю, что веса для статусов «решено», «закрыто» и «архив» должны по-прежнему применяться внутри категории.
Я понимаю вас насчет автоматического таймера архивации… это дополняющая функция, но, я думаю, мы можем сначала получить от этого пользу и без неё.
1 лайк
Я бы с этим не согласился. В теме может быть хороший ответ, но автор оригинального поста не удосужился отметить его как решение, либо для старых тем решения просто не были доступны и т. д.
У открытых тем есть преимущество в том, что их можно поднять, но я бы не придавал этому слишком большого значения. Мне скорее нравится видеть более релевантный контент по ключевым словам.
Что касается архивированных тем, то здесь я согласен — для меня это контент, который уже не актуален, и ему можно придавать меньший вес.
2 лайка
Почему такая тема была закрыта? (И заранее: «Потому что сайт настроен на закрытие тем через N дней» — это ответ на вопрос как тема была закрыта, а не почему.)
3 лайка
Я считаю, чтобы сделать это изменение управляемым, нулевая фаза должна быть тривиальной:
- Добавить настройку сайта
prioritize_solved_topicsсо значением по умолчаниюtrue. - При значении
trueприсваивать решённым темам 1.1 безоговорочно.
Это не решает всех причуд здесь, но позволит нам быстро добиться значительного прогресса.
Проблема в том, что с точки зрения расширяемости это совсем непростое изменение.
В таблице тем нет колонки “solved” (решённые), поэтому нам приходится внедрять какое-то соединение (join) из плагина solved в пользовательские поля тем… это означает, что этот SQL-запрос нужно трансформировать довольно сложным образом:
Либо
-
Нам нужно внедрить
LEFT JOINв плагин solved:LEFT JOIN topic_custom_fields ts WHERE name = 'accepted_answer_id' AND value IS NOT NULL AND topic_id = topics.id. -
Нам нужно трансформировать это условие в операторе
CASE, что, вероятно, означает сделать весь операторCASEкомпонуемым с помощью плагина.
В качестве альтернативы мы можем обойтись чем-то вроде CASE EXISTS(...) THEN 1.1, что избавляет от необходимости использовать LEFT JOIN, но несёт свои риски.
Подумаю над этой проблемой; главная сложность здесь — понять, как добавить эту поддержку, не создав огромный хаос, учитывая, что “ядро” ничего не знает о решённых темах.
8 лайков
@mcwumbly это один из тех случаев, когда выполнение работы оказывается проще, чем её описание…
Я попытался сделать это здесь:
7 лайков
Для меня это почти всегда так! Я почти никогда не могу понять спецификацию, пока не напишу код, который, как я уверен, работает. Это (частично) потому, что я обычно пишу код для спецификации, которую не понимаю. Несколько раз мне удавалось сначала написать спецификации, как взрослый, но это довольно редко.
Хорошо слышать, что это хотя бы иногда случается и с вами тоже. 
5 лайков