Система рейтинга

[Demorey]

Распишу по подробнее систему как я ее вижу, но сначала преамбула:

Преамбула

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

Из очевидных минусов:

• Человеческий фактор - люди могут забывать оставить отзыв, оставить его без какого-то комментария, а если заставлять давать комментарий, то они будут делать это на от...стань. Некоторые люди могут быть крайне придирчивыми и в итоге будут сильно занижать оценку, вследствие чего с таким человеком не захотят иметь дело просто потому что он ставит низкие оценки.
• Возможность легкой накрутки, даже если сделать привязку что участники команд в одном проекте будут оставлять отзывы друг другу, это не будет мешать людям делать сотни фейковых проектов и добавлять туда кучу команд, чтобы потом закрыть и оставлять отзывы.

Исходя из этого, я думаю, что нам в проекте нужна более изощренная система автоматического рейтинга, которая должна как минимум исключить человеческий фактор и в перспективе должна дать ответ на очевидный вопрос "Зачем я как пользователь должен за бесплатно делать для кого-то реальный проект?" - потому что в дальнейшем, по рейтингу в нашем сервисе HR`ы смогут лучше и легче оценивать кандидатов.

Основные атрибуты

Итак мое видение основных атрибутов системы рейтинга и их взаимодействие:

	Теги	Лайки (звезды или что-то подобное)	Время жизни	Установленный срок	Возможно что-то еще
Пользователь	✅	-	-	-	?
Команда	✅	✅	-	-	?
Проект	✅	✅	✅	-	?
Задача	✅	-	✅	✅	?

• Теги
  Теги в сервисе должны быть полноценным контрактом между сущностями, если пользователь вступает в команду с определенными тегами, то в дальнейшем если команда меняет теги и затрагивает те, которые имеются у пользователей-участников, то нужно как минимум уведомлять их об этом, либо запрашивать разрешение. Если пользователь участвует в команде с соответствующими ему тегами, то при расчете рейтинга над завершенной задачей, пользователю будет начисляться доп. коэффициент. И такая же ситуация если команда с тегами участвует в проекте и закрывает задачу с совпадающими у них тегами.
  Открытый вопрос - нужно ли ограничивать теги к задачам пулом только из тегов самого проекта?

• Лайки (звезды или что-то подобное)
  По сути просто условный счетчик тех кто отдает свой голос за команду/проект, за каждые n лайков предлагаю добавлять какой-то бонус к рейтингу пользователей при закрытии задач или каких-то версий проекта (?). Лайки могут ставить только другие участники проекта, включая владельца. Так как команда будет меняться, и возможно оценка перестанет быть объективной, но люди смогут по ленте событий видеть в каком составе и проекте она получила наибольшее количество лайков (?).

• Время жизни
  По сути просто дельта от даты создания проекта до текущего дня. Многие проекты страдают от незавершенности, возможно более старые, но популярные проекты будут актуальны для команд. Думаю можно будет давать пользователям, некоторый бонус при поддержании таких проектов (?).
  У задач все наоборот, чем дольше растягивается задача после дедлайна, тем меньше будет коэффициент при расчете, а может даже и отрицательный.

• Установленный срок
  Дедлайн задачи. Тут все просто, успевает в срок - получаешь почет и уважение (+бонус к рейтингу), а если нет, то идет система расчета от "Времени жизни" задачи, чем дольше тем хуже.

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

[gfg7]

• Теги

нужно ли ограничивать теги к задачам пулом только из тегов самого проекта
Нет, в ходе работы над проектом могут появляться задачи, которые не относятся к концепту/необходимым навыкам проекта
Пример, в проекте появилась одноразовая задача на простенькую аналитику чего-либо -> изменять теги, описывающие проект из-за такой мелочи? привлекать тем самым через поиск по тегам аналитиков, которые не нужны в данном проекте на постоянной основе? - ну нет, получается кликбейт соискателей по тегам

запрашивать разрешение
Владелец на то и владелец, что рулит всем
Кому не нравится, может выйти из команды или проекта

Мне вообще кажется, что по проектам с тегами мы пошли куда-то не туда в макетах
Теги дают возможность более простого поиска и краткое техническое описание проекта
Нужно разделить теги на необходимые навыки (как раз для поиска соискателей, тут и навыки, и специализации) и теги проекта (описание технологий и пр проекта, специализаций нет!) - я напоминаю, все теги мы вытягиваем с хабра, там есть специализации и навыки (soft/hard скиллы)

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

• Лайки

Лайки могут ставить только другие участники проекта, включая владельца
Абсолютно против, мне это не нравится - идти по той же дороге, что синии
Идея лайков была взята с звездочек гитхаба, лайкать могут все, кого заинтересовал проект/команда своей деятельностью - эти звездочки можно, по сути, выделить в список избранного, у нас же будет лента новостей, как никак, тут все из моих предложений по этому функционалу было завязано на этом

[Demorey]

Пример, в проекте появилась одноразовая задача на простенькую аналитику чего-либо -> изменять теги, описывающие проект из-за такой мелочи? привлекать тем самым через поиск по тегам аналитиков, которые не нужны в данном проекте на постоянной основе? - ну нет, получается кликбейт соискателей по тегам

На этот счет я того же мнения, но с точки зрения твоего кейса - рейтинг будет начисляться и за выполнение задачи как таковой, даже если теги там вообще отсутствуют, все атрибуты системы лишь дают бонус в виде коэффициента при расчете. По поводу того что нужно в сам проект добавить в малозначимый для проекта тег, чтобы просто добавить его для разовой задачи, звучит глупо, согласен, но кликбейта для поиска не получится, если мы все таки добавим отдельный список тегов в сущностях по которым идет набор.

запрашивать разрешение
Владелец на то и владелец, что рулит всем
Кому не нравится, может выйти из команды или проекта

По идее да, но тогда нужно хотя бы присылась уведомление хотя бы владельцам команд, что в таком то проекте в котором они состоят поменялся список тегов.

Мне вообще кажется, что по проектам с тегами мы пошли куда-то не туда в макетах
Теги дают возможность более простого поиска и краткое техническое описание проекта
Нужно разделить теги на необходимые навыки (как раз для поиска соискателей, тут и навыки, и специализации) и теги проекта (описание технологий и пр проекта, специализаций нет!) - я напоминаю, все теги мы вытягиваем с хабра, там есть специализации и навыки (soft/hard скиллы)

Ну пока что это не реализовано, но даже если так, то в работе над некоммерческими проектами думаю не столь важны софт скилы, мне кажется наш сервис больше про умение работать с определенными технологиями. Но думаю это тоже надо обсудить более детально.

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

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

Мне самому такой подход не нравится, я высказал его, так как с точки зрения такого простого "рейтинга" будет слишком простой способ накрутки, если это сможет делать кто угодно, но если рассматривать с точки зрения избранного/подписки, то в этом есть смысл, но тогда нужно будет подбить в расчет коэф-та за них более сложную схему, например высчитывать его за суммарный рейтинг лайкнувших пользователей, чтобы избежать абуза.

[picolino]

Обсудили backend-составом концепцию рейтингов.

Мы идем в историю с автоматизированным начислением рейтингов.
На какие ресурсы опирались:

• stackoverflow.com
• habr.com
• github.com

Появляется 2 типа рейтингов:

Звезды

Звезды можно ставить на проекты. 1 пользователь может поставить 1 проекту звезду только 1 раз. Функционал аналогичен звездам на GitHub.

Пользовательский и командный рейтинг

Данный тип рейтинга выступает в роли основного мотиватора к реализации различных проектов.

Рейтинг присутствует на сущности "команда" и "пользователь". Это один и тот же тип рейтинга.

Пользователь может получить рейтинг за выполнение задач.
Команда получает рейтинг за выполнение задач пользователями-участниками команды в рамках проекта.
Пользователь-участник команды может "жертвовать" свой рейтинг в пользу общего рейтинга команды

Количество рейтинга, получаемого пользователем, определяется различными параметрами задачи и проекта (например, количество лайков на проекте).

Открытые вопросы

• На основании каких параметров задачи происходит увеличение коэффициента получаемого рейтинга при ее выполнении
• Есть мысль сделать рейтинг для каждого тега у пользователя по аналогии со stackoverflow. Чтобы показывать насколько тот или иной пользователь владеет той или иной технологией.
• Функционал кармы. Пользователь без рейтинга не может выполнять часть функциональности. Это позволит избежать возможностей к накрутке рейтинга по договоренности

[Demorey]

На данный момент система расчета рейтинга выглядит следующим образом:

• Выполненная задача по умолчанию стоит 10 единиц рейтинга
• Рейтинг у каждой сущности делится на 2 типа: Счёт навыков (Score) и Общий рейтинг
• Рейтинг в каждую сущность отправляется в виде N единиц рейтинга и списка тегов самой задачи, для каждой сущности N рейтинга отправляются в Общий рейтинг и N/Tags поступают на счет каждого соответствующего тега сущности в виде Score
• Распределение рейтинга идет следующим образом: 5% - идет владельцу проекта в виде общего рейтинга, от оставшейся части 20% идут в рейтинг команд-исполнителей, 80% распределяется на всех пользователей-исполнителей

В дальнейшем, скорее всего, система расчета претерпит изменения. В данный момент в системе расчета отсутствует бонус от звезд проекта и возможность конвертировать Общий рейтинг пользователей в Общий рейтинг команды. Также отсутствует возможность тратить Общий рейтинг на какой-то функционал.
Также если задача была единожды закрыта, то при повторном открытии рейтинг начисляться уже не будет.

[Demorey]

Пример:
Задачу делали 2 пользователя из одной команды.
В задаче указаны теги: c#, sql

После выполнения задачи рейтинг распределяется следующим образом:

• Овнер проекта получает 0,5 Общего рейтинга из изначальных 10 единиц за задачу.

• Пользователи получают (9,5/2)*0,8=3,8 единицы Общего рейтинга и 3,8/2=1,9 единиц Счета (Score) на каждый навык пользователя который присутствовал у задачи.

• Команда получает (9,5/2) *0,2=0,95 единиц Общего рейтинга за каждого пользователя из команды, который выполнял задачу - Итого 0,95 *2=1,9 единиц Общего рейтинга команды. И на каждый из 2 навыков которые были у задачи команда получит 1,9/2=0,95 единиц Счета навыков (Score).

[picolino]

А разве у команд мы будем делать счет навыков? Я пока не вижу в них большого смысла

[Demorey]

А разве у команд мы будем делать счет навыков? Я пока не вижу в них большого смысла

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

[picolino]

Ну вот я тоже не понимаю, счет навыков у команд кажется вообще не объективным показателем

[Demorey]

Тогда надо заранее продумать экономическую составляющую, потому что иначе придется делать вайпы