16 марта 2009 в 11:09
На основании обсуждения поста "Сравнение модулей кармы, репутации и рейтинга", делаю выводы про то, какой должна быть толковая реализация "кармы". Кроме того, Теоретические измышления, толкование понятий и разницу между ними читайте в этом самом посте ("Сравнение модулей кармы, репутации и рейтинга"), а здесь я хочу собрать все идеи и предложения, которые относятся именно к карме.
Кроме кармы, выделились ещё такие направления как "опыт" и "репутация", но об этом позже...
Напомню, что карма - это отношения пользователя и системы. За плохие деяния пользователя наказывают, за хорошие - поощряют.
Назначение системы "кармы"
- создания благотворной почвы для развития сообщества,
- защита сообщества от вандалов и тех, кто пытается разрушить сообщество,
- защита самой системы от разрашения,
- поощрение и направление деятельности сообщества.
Что такое "хорошо" и что такое "плохо"?
Для сайта должно быть сформировано 2 списка: плохие дела и хорошие дела. Для разных сайтов это будут разные списки, но всё таки можно сделать некоторые обобщения, потому что это не оффлайн, а сеть и действия пользователя на сайте ограничены возможностями движка.
Плохие поступки:
- публикация спама. Оценка: система и пользователи.
- публикация бессмысленных комментов или статей. Оценка: только пользователи.
- вредные действия по отношению к системе (сайту). Например, попытки взлома или разрушения. Оценка: система и пользователи.
Хорошие поступки:
- публикация качественного контента (комментарии или посты). Оценка: только пользователи.
- участие в развитии системы (например, сообщения о спаме, участие в улучшении сайта и др.). Оценка: только пользователи.
Правила сайта
Правила сайта (системы) должны быть известны пользователям, чтобы они знали, что хорошо и что плохо. В правилах также нужно описать методы наказания и поощрения. Варианты реализации:
- можно использовать модуль Legal, который показывает правила сайта при регистрации и вынуждает согласиться с ними. При внесении изменений он опять же требует каждого пользователя согласиться с ними снова.
- Можно сделать простую текстовую страницу, где будут приведены правила сайта и обновлять эту страницу в случае необходимости.
Первый вариант более человечный, а второй стоит на позиции "незнание закона не освобождает от ответственности".
Наказание и поощрение
Здесь мы ограничены не воображением, а реальными возможностями движка:
-
автоматическая смена ролей (как это делает User Karma).
Krotty@drupal.org">Krotty@drupal.org предложил сделать роли, которые будут исключаться из автоматического назначения:Не хватает возможности исключения ролей для которых карма бы считалась, а дополнительные роли, соответствующие значению кармы - не назначались бы.
Пример. На сайте создана роль - "временный бан", не дающий возможности пользователю использовать часть сервисов сайта. Если мы же используем еще и карму, то этот пользователь получит еще и роль определенную его значением кармы, которая отменит ограничения роли "временный бан".
Но это не недостаток UserKarmа как таковой, а следствие того, что итоговые права для пользователя при наличии нескольких ролей определяются операцией OR. - удаление проблемного комментария или поста пользователя
- временное отключение пользователя
- удаление всего контента пользователя (как бы с водой и ребенка не вылить...)
- удаление пользователя (имеет смысл, если новый пользователь не имеет таких же прав как и удаляемый)
- материальное вознаграждение или ущерб (например, если на сайте есть платная регистрация, то удаление пользователя это материальное наказание. Поощрение: увеличение скидки на покупки в собственном магазине или начисление виртуальных тугриков, которые можно обменять на что-то реальное)
- другие методы поощрения и наказания - предлагайте (методы должны быть автоматизированными).
Методы анализа действий пользователя
Автоматическая оценка силами системы
Некоторые действия система может отслеживать сама. Вот они:
Плохие поступки
- публикация спама
- вредные действия по отношению к системе - полностью учесть не удастся, нужно использовать также оценку пользователей.
Хорошие поступки
- участие в развитии системы (например, сообщения о спаме, участие в улучшении сайта и др.) - полностью учесть не удастся, нужно использовать также оценку пользователей.
Не так уж и много, к сожалению. Может быть я что-то упустил?..
Оценка действий другими пользователями системы
Оценка других пользователей является субъективной, но они тоже часть системы и нужно это мнение учитывать. Список того, что пользователи могут оценивать:
Плохие поступки
- публикация спама.
- публикация бессмысленных комментов или статей.
- вредные действия по отношению к системе (сайту). Например, попытки взлома или разрушения.
Хорошие поступки
- публикация качественного контента (комментарии или посты).
- участие в развитии системы (например, сообщения о спаме, участие в улучшении сайта и др.).
Корректировка субъективности оценок пользователей
Для снижения субъективности оценки действий других пользователей нужно как-то учесть личность того, кто оценивает.
Речь вот о чём: есть действие, но кто-то сочтет его ужасным, кто-то плохим, кто-то терпимым, кто-то полезным и так далее. Это как-бы лояльность пользователя к данному виду действий. Нужно учесть, что люди по разному оценивают действия направленные на других и направленные на себя.
Если удастся получить информацию о том, как конкретный пользователь оценивает данное действие, описанное в правилах, то можно делать автоматическую корректировку его оценок.
Проблема в том, что со временем эти оценки могут меняться...
Как все это можно реализовать?
Например, можно при регистрации показывать не правила в виде текста, а под каждым пунктом показывать голосовалку, где пользователь должен поставить свою оценку этому действию (но не мере наказания или поощрения!).
Но как учесть то, что со временем пользоваля, ранее лояльного к спаму, начнет это доставать и он станет ярым борцом против спама?...
Виджет для оценок
Dan предложил использовать разные шкалы для оценок:
1. Сделать многомерную шкалу. Делить все оценки на хорошие и плохие, и ещё хуже, смотреть разницу - дело бесполезное, на мой взгляд. Например человек может писать хорошие статьи в свой блог, но сильно флудить в форумах. "Хорошо" это или "плохо"? Нет, это просто две разные оценки: "полезные статьи", "флуд в коментах". Как их будет интерпретировать админ - его сугубо личное дело.
Другими словами, модуль должен позволять создавать несколько шкал оценок и "привязывать" начисление очков дополнительными модулями к разным шкалам.
ingumsky@drupal.org">ingumsky@drupal.org написал:
Обычно читатель готов воспользоваться только одной шкалой и только для того сообщения (комментария, видеофайла и так далее), которое его зацепило. Причём, по сути, не так важно, какова градация это шкалы — реально используется около пяти значений, не больше. И то читатель поставит оценку только в том случае, если объект оценивания вызвал у него сильную реакцию.
Причём, если смотреть по комментариям на всяких фотосайтах, охотнее голосуют те, кто хочет похвалить, а не поругать (ещё одно «узкое место»!) И, кстати, оценки обычно ставят, отталкиваясь от максимальных значений. Возмущённый читатель, не раздумывая, поставит «минус пять», восхищённый — «плюс пять», а вот тройки и двойки ставить будут вряд ли. По опыту могу сказать так же, что на оценку материала может большое влияние оказывать то, как голосующий относится к предмету материала, а не а не к самому материалу. Вот у меня сайт болельщиков футбольного клуба — после победы над сильным соперником пользователи поставят хорошие оценки любому отчёту о ней, а после поражения — вряд ли найдётся два-три человека, которые вообще сунуться голосовать. В общем, Ваша идея действительно очень интересна, но я не уверен, что выполнима.
Вывод, шкала оценок должна иметь 5 плюс-минус 2 значений и нужно учесть эффект Полианны, когда пользователи дают только позитивные оценки, а негативные стараются не давать.
Виджет для разных оценок может быть и один. Например такой список вариантов:
- смешно - НЕ добавляет репутации автору, но учитывается иначе. Например, для рейтинга (пузомерки)
- спасибо - НЕ добавляет репутации автору, но учитывается иначе. Например, для рейтинга (пузомерки)
- +1 - добавляет +1 к репутации автора
- +2 - добавляет +2 к репутации автора
- +3 - добавляет +3 к репутации автора
И это не моя идея. Это из статьи, ссылку на которую я привел с самом начале обзора. Посмотрите внимательно - я нахожу это лучшим решением на данный момент. Привожу ссылку ещё раз:
http://www.rsdn.ru/?forum/Info.aspx?name=info.forum.rating - описание виджета для голосования.
Связь с оффлайн жизнью
peter предложил:
1. Возможность админу добавлять определенное количество кармы/репутации (по результатам действий в реале)
Так как карма - это отношения пользователя и системы, то это к карме не относится. То есть карма не учитывает действия, репутацию пользователя оффлайн, а только действия в системе.
Учет репутации и опыта
Если для расчета реакции системы на плохие и хорошие поступки будут учитываться репутация и опыт, то мы получим систему, которая будет позволять беспредел "старикам" и заслуженным, а наказывать только новичков. Поэтому я думаю, что честнее будет наказывать и поощрять всех одинаково. Хотя я понимаю, что система управления типа "дедовщина" тоже имеет свои плюсы, но прощу учесть, что речь идет о некой идеализированной реализации кармы, которая соседствет с идеальной системой репутации и ещё более идеальной системой опыта.
Таким образом, системы кармы, репутации и опыта должны сосуществовать рядом, но не влиять на карму.
Комментарии
Спасибо, Влад!
Наказание и поощрение
В качестве наказания может применяться временное ограничение прав пользователя. Это может быть ограничение на публикацию новых материалов или комментариев, причём как полное ограничение (запрет), так и частичное (не более двух в день и т.п.).
В качестве поощрения, как мне кажется, может быть использован и доступ к дополнительным возможностям. Например, временный доступ к аудио- или видео-контенту, закрытым разделам, инвайты, если ресурс закрыт и т.п.
Методы анализа действий пользователя
Нанесение ущерба системе и помощь в её развитии — по сути, одна сторона одной медали. Причём система считает статистику, а пользователь оценивает, не наносит ли это вреда. Фактически весь контент, не отмеченный пользователями как «плохой», является хорошим и (теоретически) идёт системе на пользу.
Есть большая проблема в оценке некоторых действий пользователя, так же требующих «признания». Предположим, у меня есть wiki-сайт, на котором пользователи создают статьи. Статьи могут отличаться по своему качеству и это ведёт к разным оценкам. Но задача организатора такого сайта, прежде всего, — не оценка пользователей, а создание ресурса с максимально хорошим содержимым. Соответственно, он (я) вводит редакторов, которые могут править существующие статьи, приводя их к общему выводу и выводя на высокий уровень. Как правильно оценить такую работу, безусловно полезную для системы? Как сделать так, чтобы оценка, которую ставят статье, считалась не только для автора, создавшего быть может «дурную» статью на хорошую тему, но и для редактора, который сделал статью хорошей?
«Если удастся получить информацию о том, как конкретный пользователь оценивает данное действие, описанное в правилах, то можно делать автоматическую корректировку его оценок.
Проблема в том, что со временем эти оценки могут меняться...»
Я думаю, что имеет смысл отталкиваться от поведения самого пользователя, выставляющего оценку, на сайте, причём брать в расчёт не только оценки ему за подобные действия, но и его оценки нарушениям. Плюс ввести поправочный коэффициент для новых пользователей, для которых статистическая погрешность в вычислениях их действий и оценок пока ещё слишком велика.
Виджет для оценок
Подумалось вот что. Оценки в обязательном порядке должны быть анонимными. То есть получатель оценок не должен знать, какую оценку его материалу выставил тот или иной пользователь. Открытость подобных рейтингов обычно отрицательно сказывается на объективности оценки материала и соответствии этой оценки реальному мнения пользователей о нём.
По-прежнему не представляю, как реализовать одинаковое понимание «спасибо» и «+1» для пользователей с разным уровнем культуры (в том числе сетевой). То, чем для меня будет «спасибо», например, для кого-то окажется «плюсадын». Возможно имеет смысл изменить ярлыки оценок (это я как раз про +1, +2 и +3) таким образом, чтобы вырвать их из культурного поля «плюсадына/плюстыщи».
Связь с оффлайн жизнью
Оплата хостинга сайта (помощь в её осуществлении) и техническая реализация определённых вещей на сайте вполне относятся к «развитию системы». Почему бы не оценивать их тоже? Это, кстати, в полной мере относится и к редакторам, упомянутым мной выше. Да, давать администратору инструмент «накручивания» «кармы» не слишком хорошо, но это позволяет компенсировать некоторые недостатки подсчёта этой самой «кармы» системой.
Учет репутации и опыта
Мне кажется, что стоит просто учитывать количество пользы для системы и в процентном сообщении тоже. Если человек с очень большим и полезным вкладом допустил пару комментариев флуда, его безусловно стоит пожурить и отметить это нарушение в логах, но это совсем не то же, что новичок с минимальным полезным вкладом или вовсе без него, который с места в карьер начинает флудить. Люди — не машины, поэтому нужно делать определённую «скидку» тем, кто в целом приносит системе больше пользы, чем вреда.
Да, я думаю, что это относится больше к юзабилити этого самого виджета - он должен быть интуитивно понятен. Названия конечно можно поменять.
Ок. Вопрос вот в чем. Оплата хостинга или работа редактора нуждается в реакции системы на это? Или нужна "доска почета". Второе реализовать проще.
Ручная корректировка админом состояния дел сайта я думаю, что должна быть. Так - на всякий случай...
Согласен. Нужно это как-то учесть - я подумаю. Спасибо за идеи.
Мне кажется, что работа редактора, например, нуждается в этом. Особенно это касается тех случаев, когда редактором может выступить почти любой (любой?) пользователь сайта, а значит именно улучшением существующего содержимого, а не созданием нового, юзер может приносить гораздо большую пользу системе.
Да, это так. Часто наводить порядок занимает больше времени, чем создать что-то новое.
Ок. Мне нужно это обдумать, это несколько неожиданный для меня поворот.
Мне кажется, что в случае с редакторами вопрос мог бы решиться, если бы применялись ревизии текста (а-ля редакции в Вики). В таком случае оценки, полученные материалом можно было бы распределять в соответствии с тем, кто из авторов какой вклад внёс. Осталось только понять, какими критериями здесь определять привнесённую пользу — «весом» изменений, дельтой оценки текущей и предыдущей или и тем, и другим.
Вообще, Влад, большое Вам спасибо за поднятую тему! Я не могу сказать, что для того единственного сайта, которым я занимаюсь, карма, репутация и опыт очень важны, но сами по себе поднятые задачи очень интересны. Надеюсь, что я смогу вам помочь хотя бы в выявлении возможных проблем и узких мест.
Ревизии в друпал есть. Например у этой статьи их штук 15 - после каждого изменения создаётся новая версия и их можно видеть на вкладке "Версии". Можно их сравнить между собой (модуль Diff).
Но как учесть вклад разных людей в создании хорошей статьи?...
Можно давать оценку не ноде, а этой самой ревизии и как-то делить между теми, кто вносил изменения. Но как?
Это похоже на то, как мы платим, например, за вещь, но её создатели использовали законы физики, которые открыты до них, математику, химию и прочее и никто не делает отчислений тем, кто это открыл... А часто было так, что эти самые открыватели не имели что есть в свое время, а теперь этим пользуются все. Например, изобретатель гипсокартона ничегошеньки не получил со своего изобретения, а теперь все пользуются...
Ок. Нужен алгоритм оценки вклада разных людей (авторов) в создание контента. И кажется мне, что это может сделать только человек, потому что количественные и цифровые методы оценки текстов не покажут насколько изменилось качество контента. А для оценки улучшения нужно видеть разницу между текстами (это не проблема), но нужно прочитать оба текста и включить мозг.
Как вариант - по аналогии с википедией статья может развиваться (дополняться, изменяться), а в какой-то момент она фиксируется. Далее человек смотрит статью и определяет кто-сколько вложил в эту статью разделяя 100% между авторами. Далее согласно этому долевому участию голоса или оценка статьи делится между участвовавшими авторами.
Пока это самый реальный вариант.
Да, безусловно, лучше человека оценить вклад, особенно такой специфический, не сможет никто, но можно попробовать продумать более механизированные варианты подсчёта. Я вижу себе это так. Статья может получать оценки в любой момент, каждая новая правка создаёт новую ревизию и фиксирует оценки, полученные статьёй в ревизии предыдущей. Для сравнения вклада на каждой ступени в автоматическом режиме можно использовать следующие критерии: дельта оценок соседних ревизий, дельта объёма соседних ревизий, время существования ревизии в качестве последней (то бишь выдаваемой читателю), iscleared (проверка, не было ли содержимое удалено полностью, то есть, не осуществлялась ли накрутка количества ревизий и авторства финального текста). По идее, между дельтой оценки и временем действия ревизии существует прямая связь (рассчитываем через отношение одного к другому?), которая в свою очередь связана с увеличением контента. Если контент значительно прибавился и оценка стала расти стремительнее, значит вклад, внесённый в ревизию, действительно хорош.
Господа, вы зароетесь.
Плохо и хорошо - очень эфемерные понятия. Я вообще не понимаю _зачем_ нужно делить на плохое и хорошее! В системе есть два функционала: начисление очков за определённые действий по разным шкалам, обработка шкал (отдельно или совместно). Всё! Где тут плохо, а где хорошо?
Разбейте задачу на части и максимально абстрагируйтесь.
Мои две копейки:
1. Думаю имеет смысл использовать VotingAPI. Влад, посмотри внимательно на этот модуль и как другие модули с ним работают. Каждой шкале можно присвоить свой ключ, и сохранять очки(баллы?) с этим ключом, используя VotingAPI. Так же не забудь прошерстить UserPoints. Возможно на начальном этапе написания модуля можно будет использовать данные этих модулей. Ну и интеграция с ними не повредит.
2. Почему ты хочешь использовать чётко определённое количество шкал (пять)? Пусть пользователь (админ в смысле) сам решает сколько ему нужно шкал. Нужен UI - добавить шкалу / удалить шкалу. У каждой шкалы - свой ключ.
3. Зачем делить всё на плохое и хорошее? Не суди, да не судим будешь
4. Ещё раз напоминаю про абстракцию и интеграцию! Смотри: интеграция с VotingAPI и UserPoints даёт нам доступ к шкалам и кучи модулей оценки содержимого (и не только) сразу и на халяву. Интеграция с actions/trigers и им подобным, позволит использовать субмодули к ним, которые сделают всю чёрную работу (смена ролей, рассылка писем модераторам и т.д.). Ну интеграция с views сам понимаешь...
По сути, модуль который ты задумал - чистая абстракция, ибо весь функционал который тебе нужен уже есть в других модулях. Всё что нужно - написать прослойку для склейки данных и функций.
Зацепило. Не стоит использовать цитаты, не зная их контекста. "Не судите, да не судимы будете" - это слова Христа, но речь шла как раз о том, что "каким судом вы судите, таким и вас будут судить". Мысль не в том, чтобы не судить, а судить честно и быть готовым самому быть измеренному свой же линейкой. То есть, если ты никого не судишь и тебя никто трогать не будет, но если ты судишь, то будь готов, что и тебя будут судить по твоим же правилам.
Зачем это? Да затем, что люди судят, судят всё время и постоянно, но хотят судить других, а не себя. Это в общем-то понятно. Человек может быть "за" смертную казнь для другого, но "против", когда это касается его лично.
Ок. Судить - это выносить суждение, определять принадлежность, оценивать. Мы делаем это каждый день и постоянно. А кто не делает, тот имеет какие-то комплексы. Например, я читаю пост и понимаю, что это спам - я даю ему оценку, это моё суждение. Я принимаю решение его удалить. Суд. Почему? Потому что спам это плохо.
Про хорошо и плохо я пока не буду ничего писать.
По реализации кармы. Я понимаю, что многое дублируется и уже реализовано. Но мне кажется, что именно то, что этот функционал размазан по разным модулям и затрудняет использование.
Я хочу определиться с тем как это должно быть в идеальном случае реализовано, а затем уже подумаю как это лучше всего сделать. Может быть новый модуль, может быть грамотная настройка существующих - это не принципиально. Главное получить желаемый результат.
Я делал модуль, который реализовывал action, но не увидел никаких преимуществ в этом подходе и переделал, чтобы проще было устанавливать его. Или я чего-то недопонял в этом механизме?
Контекст знаю, потому и смайлик.
Пусть другие сами думают, что у них хорошо, а что плохо - не стоит навязывать своё виденье - я это имел ввиду.
Имхо это не идеальный случай, а подробный частный.
Я думаю там всё понятно
Просто большинство действий достаточно распространено, во-первых, а во-вторых, пользователи могут напридумывать таких извратов, что в ядро модуля включать не захочется, а придумывать свой plug-api - смысл, если уже есть action?
Безусловно это главное. Просто хочется параллельно замучить тебя советами )
Я терпеливый и занудный - замучить меня трудно... но можно.
То есть получается, что на мои actions другие могут тоже вешать свои обработчики?
Ок. Если я описал очень частный случай, то как должен выглядеть самый общий?
Не совсем. Action можно вешать на trigers. Например регистрация пользователя это триггер (событие), на него можно повесить отсылку письма одмину (это действие). Можно писать как тригеры, так и действия. Например триггер - достижение определённого значения баллов по такой-то шкале или вычисление баллов по формуле нескольких шкал (например шкала1 + шкала2 - шкала3). На этот триггер админ может повесить какое-либо действо - удаление юзера, оформление ему премии, отсылку себе письма и т.д. Это уже не наше дело - пусть сам решает.
Всё это дело можно выстраивать в цепочки. В общем тема интересная, очень, хоть реализация в ядре 6-го мне не очень-то и нравиться...
Абстрактно. что мы знаем?
1. На сайте будет что-то происходить. Заметь, ты в этом пункте говоришь про действия пользователя ("публикация...", "действия...", "участие..."), а почему участие пользователя обязательно? Например мы говорили про опыт, в частности - срок регистрации юзера - он может вообще ничего не делать, но очки за "давность лет" ему вполне могут начисляться. Так? Или например запуск хрона. Юзер имеет к этому какое-то отношение? Нет. Но по этому событию, например могут аннулироваться временные баны. И т.д. и т.п. Ещё раз - "на сайте что-то происходит".
2. Требуется хранить данные. Сколько и какие - неизвестно.
3. Необходимо предпринимать какие-то действия. Пункт аналогичен первому - эти действия не обязательно привязаны (направлены на/против) к пользователю.
Смотря на всё это безобразие, мне видится логичным использовать VotingAPI и Action/Triggers как основы, на которой строить функционал модуля.
для информации:
rules я смотрел, но не сумел заставить работать, хотя перечитал доки. Его позицируют как замену стандартному модулю триггер, но я не разобрался.
Я не против использования этих модулей. Просто на данном этапе я хочу понять что именно нужно, а не как это реализовать. Сначала ТЗ, а затем уж реализация.
Понятно. Я думал, что основное уже проговорено, остались мелочи.
Надеюсь, поезд еще не ушел ;-).
Не так давно я исследовал проблемы механизмов голосования. Небольшой набор мыслей есть у меня в ЖЖ. Если что-то понравится, пользуйтесь — мне не жалко. Единственная просьба — дайте знать, что пригодилось.
Пока оттачивается идея и принципы. Я думаю, что в этом деле это самое сложное. Реализация проще, так как многое действительно уже сделано.
PS. Мысль о разных весах оценок в зависимости от близости к краю диапазона - интересная. В принципе это даже нормально. Пользователь поставил оценку - это его право. А уж как эту оценку трактовать - право системы.
Про право системы очень верно подмечено, спасибо. Люблю емкие формулировки.
Края диапазона — особые точки, поскольку выставление близких к ним оценок сильнее всего влияет на результат. В некоторых ситуациях может быть необходима несимметричная функция, которая режет один край сильнее, чем другой. Как тут уже отмечали ниже, для проверки работоспособности и качества метода нужна «живая» статистика.
Думаю, при использовании этой технологии в модуле следует дать админу возможность легко настраивать вид функции. Хотя бы даже в форме альтернативы: параметры для стандартной функции или указание коллбэка.
2pro-online.ru
Несколько лет назад я занимался проблемой подсчёта средней температуры в системах АСУ ТП при возможной недостоверности исходных данных. Задачи довольно похожи. Кстати для проверки системы хорошо бы иметь массив тестовых данных, чем больше- тем лучше, а ещё лучше - несколько массивов.
Прочитав Вашу статью, подумал, что это всё сильно напоминает нормальное распределение. Можно тупо предположить, что вес голоса прямо пропорционален "вхождению" параметра в норм. распр.
Нет, тут, я думаю, не нормальное распределение. Мы не можем априори указать, каким будет распределение честно выставленных оценок (в отличие от поля температуры из вашего примера, которое, я думаю, хоть как-то предсказуемо). Если, используя пример с оценкой фотографий, перед нами шедевр, абсолютное большинство голосов будет близко к верхнему пределу. Если явный отстой — к нижнему (плюс, разумеется, всплеск в максимуме от накрутки). Для спорных и неоднозначных работ распределение вообще может быть любым — хоть равномерным. А если фото еще и, например, скандальное какое-нибудь, но хорошо сделанное, вполне реально получить и два «честных» горба.
Если мы имеем много голосов около одного конца шкалы (но не на нем), и некоторое количество (возможно, даже большее) — точно на другом конце, можно с высокой степенью достоверности утверждать, что имеет место накрутка. Но предложенная мной система прекрасно справляется с такой ситуацией. Скажем, можно выставить такие параметры шкалы [0, 10], при которых среднее от 1 оценки «1» и 10 оценок «10» будет около 5, а от 1 «1» и 10 «9» — около 8.
Скажу честно, описанную функцию я взял «с потолка», подобрав красивый вид графика. По-хорошему, конечно, надо бы провести исследование, да только вот я уже начал забывать, как это все делается, — давно математикой не занимался. Но, сдается мне, на практике это будет всяко лучше «тупого» среднего арифметического.
И еще надо бы исследовать эту штуковину на стойкость к взлому. Иначе мы рискуем потратить много времени, и получить в результате голосовалку, которая «ломается» лишь немногим более сложно, чем традиционная.
Интересная переработка модуль User Points: http://www.drupal.ru/node/26996
Но это как раз вариант с отрицательной оценкой. Лучше, когда отрицательных оценок нет вообще.
Хабр: идаельная карма - ее отсутствие.
Хабр отказывается от кармы
Химический Али
С первым апреля?
Ну, все думают, что 1 апреля
За 2 года что нибудь продвинулось? А то Карма и репутация так и нет их нормальных.