#5280 - Karma system

This is already WIP for a v11 site being built. Whether this addon will be included as a Composr non-bundled addon or published on the Composr forums is TBD.

Interesting. Sounds cool.

I think it's right that this should be a non-bundled addon. People would get confused having both this and points. This should be able to operate without points being installed, as people may want karma instead of points, having both would potentially be considered making a site too confusing.

cns_implicit_usergroups hooks could be used to put people into certain groups based on karma, allowing them to have certain privileges. A good example hook could be shipped with the addon - or - have it work out of the box via config options that the hook uses (better).

Karma should probably work via a ledger table, similar to how points now does. And the positive/negative numbers could then be derived from that. Sounds like voting power would be included into that, just like how forum poll votes are now handled (or possibly fields for all the factors you list, and then a config option specifies which is actually used in the calculation).
Probably the whole table should be browseable and moderatable by staff.

Random inside, I'd like to see the term "Crowdsourced moderation" used in the description of the addon. Calling it Karma is good, but I think "Crowdsourced moderation" is a good describer.

Yes, the karma system will be able to work without the points system. The only requirement is Conversr (it doesn't even need conversr but I intentionally made that a requirement so it doesn't conflict / get confused with reputation systems of other forum softwares; it'll disable itself when conversr is not being used). All other addons are recommendations, but if they're not installed, the karma system will simply ignore them and hide the relevant config options for them.

I agree on cns_implicit_usergroups. I'm not going to implement that in the karma system itself, though. That will be for developers who wish to tap into the karma API and make their own implicit usergroup logic. But definitely something that can be used with it.

A ledger / log table is a good idea. It's currently just using CPFs. But I will keep that in mind and probably put one in for abuse prevention.

I'll also add the crowdsourced moderation term in there; I agree this can be useful for such.

Developing the karma system has been a little difficult overall; initially, before I went with the "all hooks" route of development, I ran into two cases where the karma system would have conflicted with another non-bundled addon because they already had an override on a file the karma system needed to be able to override. And one of those addons, I believe it was idolisr, I couldn't simply mark as a conflict addon because I was going to have the karma system utilise it if installed. So I had to go the "all hooks" route. But it comes with a couple caveats, like karma not getting automatically reversed if certain things are reversed, like warnings or votes. I could have remedied this by developing a couple new hook types in the main Composr repository, but I did not want to go that route just to accommodate a non-bundled addon.

So for the time being, karma is processed in different ways depending on the addon... for awards, ratings, poll votes, and giftr, it's a cron hook that runs minutely. For formal warnings and member bans, it's an action log hook. And for charged points from a warning, and sending members points, it's a points transact hook. I'm still trying to figure out probation (bad karma for probation time). That's tricky since probation time can be extended, and there's no way of knowing the original value from any hook.

It might be over-complex for you, but in v11 it is now possible for multiple addons to override the same file using contentious_overrides hooks.

For the case of require_code, the call_included_code function inside global.php will call call_included_code on any contentious_overrides hooks. It is possible for it to load up the code from $path, alter it, and then return the new code in $code. That is then the code that will be loaded with eval on global.php line 340.

Aha, I didn't know it was possible to override code with that; I thought it was only for templates / js / css. I'll check into that, thank you! I was going to use contentious for overriding the templates to inject the karma onto forum posts on the left bar. So that'll be good practice.

Update: The karma addon development is moving forward. I decided the primary basis of how karma will interact with other addons is contentious_overrides hooks; it's the easiest method to avoid conflicts. Since it will heavily use these, I also added a karma unit test to test every use case to make sure karma gets correctly applied (and removed).

Perhaps Karma reputation could instead be represented as a doughnut chart / ring around a member's avatar. And on hover, it would show their karma information. I think that would be pretty cool.

Perhaps the way the doughnut is filled is the following:
* Add a new setting to define "full doughnut threshold" (maybe we call it "vetted member karma threshold") where, when a member's good or bad karma is equal to or greater than this amount, their doughnut is fully filled in. Otherwise, it is relative to how close the good or bad karma (whichever is greater) is to this setting.
* Use theme seed color instead of green. Use theme danger red instead of red. Use slightly seeded color for portions not filled.
* The filled portion of the doughnut will, when the member has privilege to view good/bad breakdowns, be filled according to bad:good ratio.

Example, for a threshold setting of 100 karma:

* A member has 25 good and 10 bad karma. The doughnut will be 25% filled (max karma is good, 25, which is 25% of 100). The filled portion will be 28.5% red because 10 is 28% of (good + bad) 35.
* A member has 0 good karma and 100 bad karma. The doughnut will be 100% filled, and it will be all red.
* A member has 50 good and 0 bad karma. The doughnut will be filled 50% of the way. And it will have no red; it will be all the theme seed color.

The idea with this is that members can differentiate the following:
* How reputable a member is based on how much overall karma they received (% of the doughnut that is filled in). This is mainly to decipher senior members from junior members.
* How reputable a member is based on their good/bad karma ratio (the ratio of theme seed color to danger red color). This is mainly to decipher authentic members from not so authentic members.

The chart idea was too complex given the multiple canvas elements, block behavior, etc. Instead, I opted for a simple bar using relative / absolute div containers with background colors.

When permission to view karma is not granted, it will simply show the total karma (good - bad) relative to the configured karma threshold as a green bar (or it will be fully filled red if a member's karma is less than 0).

If members can view good / bad karma breakdowns, then the bar will have red, yellow, and green.

* The total amount of the bar filled will represent the relative amount of the maximum karma (good or bad) compared to the karma threshold.
* First, the higher karma is drawn... red for bad karma or green for good karma, relative to the karma threshold.
* Then, the lower value is drawn on top of the higher value as yellow, and will be filled relative to how close the lower value is to the higher value.

For example, if a member's good karma is 100 and bad karma is 75, and the threshold is 200 (see screenshot)...
* The bar will be filled, in total, halfway, because 100 is 50% of 200.
* 75% of the filled portion will be yellow because 75 bad karma is 75% of 100 good karma. The rest of the filled portion will be green for good karma.
* If bad karma was 100 and good karma was 75, then the non-yellow portion would be red instead of green to indicate they have more bad karma.

In general...
* Green is good
* Red is bad
* Yellow negates the other color / is neutral

(Click to enlarge)

Sounds great.

I do worry about overwhelming users so we need to make sure the difference from points is clearly documented. I'd say something like "Points is like how wealthy someone is, while karma is more like what their reputation. Generally those with more points would often have more karma (by earning those points by good deeds), but it is possible for someone may just have a lot of points by being very active and successful while also having some behavioral problems that karma would pick up on."

I can do that and put it on the tutorial page for the Karma addon (https://composr.app/docs/sup-adding-a-member-reputation-system.htm). Specifically, points is like a virtual currency, karma is their reputation. Not sure I'd use the wealthy language.