Что не так с тэгами и лентами и что с этим делать

Что не так с тегами

Глядя на клиент golos.id возникает чёткое ощущение, что он задумывался как аналог reddit, но что-то пошло не так. Вот смотрите: справа есть список "Тэги и топики". Можно ткнуть в любой тег и вы попадёте в отдельные ленты "новое/актуальное/популярное"! Для каждого тега свои ленты.

Теги - это ничто иное как аналог сабреддитов. Сабреддит это по сути сообщество внутри reddit, со своей тематикой, правилами и модераторами. Можно зайти в сабреддит и там будет свой Hot и Top. Можно подписаться на конкретные сабреддиты и тогда главная страница reddit будет показывать контент только из них.

Но у нас теги используются совершенно не так, а просто лепятся как попало без ума. Список тегов справа - динамический и берётся с ноды через API get_trending_tags, и в результате получается какая-то дичь. С этим пора кончать.

Как поправить

Очень просто, список тегов на клиенте должен быть фиксированным, а учитываться должен только первый тег. При постинге пользователь должен иметь возможность выбрать только 1 тег.

Фиксированный список тегов - это что-то типа традиционного "политика, экономика, музыка, программирование". В общем community решает какие категории хочет видеть. В дальнейшем можно добавлять новые теги через голосование community, а так же сделать платную услугу по запилу своего "тегосообщества" (типа chaos-legion), возможно через сожжение GBG. Теги изначально делать на русском, для иностранцев выделить тег "en", а в дальнейшем если они будут подтягиваться, запиливать им отдельные тематические "тегосообщества".

Общие ленты ("Популярное" и т.д.) тоже должны фильтроваться на предмет показа только одобренных тегов.

Что не так с лентами

У нас есть две ленты, "актуальное" и "популярное". В их ранжировании используется тот же механизм, что и на reddit, кому интересны детали, читайте прекрасную статью https://medium.com/hacking-and-gonzo/how-reddit-ranking-algorithms-work-ef111e33d0d9#.lcbj6auuw

Кратко, score поста зависит от количества положительных голосов (net_rshares), и от времени создания. Если у более нового поста столько же net_rshares, сколько у более старого, то score у него будет выше. Т.е. новые статьи вытесняют предыдущие, и срок жизни статьи в "актуальном" 3 часа, а в "популярном" - 5.5 дней (plugins/tags/tag_visitor.cpp operation_visitor::calculate_hot).

Собственно что не так, а то что лент всего две и обе они по сути Hot. Нет реального топа за неделю, месяц, год и за всё время. В новой парадигме донатов такой расклад совершенно не годится. Хорошие посты должны быть доступны долгое время через нахождение в топ лентах.

Ну и 3 часа для "Актуального" это мало, сделать там например 1 день.

С имплементацией таких топ-лент возникает проблема, т.к. механики в ноде на такое не рассчитаны:

• При закрытии окна выплат у поста значение net_rshares сбрасывается в 0, причём раньше у нас было 2 окна выплат, и сброс происходил дважды
• Голосование за посты с закрытым окном никак не влияет на net_rshares
• Нода не имеет API для получения топа по net_rshares за разные периоды времени

Таким образом, требуется внесение изменений в код:

• net_rshares не сбрасывать в 0, а сохранять (а для старого времени с двумя окнами - записывать суммарное значение rshares после отработки выплат)
• Сделать механику голосования для архивных постов, т.е. чтобы ап/флаг так же влиял на net_rshares
• Изучить возможность добавления API для получения топов: дневного, недельного, месячного, годового, за всё время. Надо понять, утяжелит ли это ноду, если да, то насколько, и не треснет ли она вообще. Альтернативно, можно строить такие топы вовсе без участия ноды, для этого достаточно только корректного сохранения net_rshares в объекте поста. Всю обработку может делать отдельный специальный микросервис, который будет отдавать топы уже через своё API