SoylentNews

martyb [soylentnews.org] writes:

History:
The code for this site is a fork of code written for slashdot. In that site's early days, it was apparent that some comments were much more interesting and informative than others. That some users would just as gleefully troll they community. Moderation was conceived as a way to sift the wheat from the chaff and help users more easily avoid the "lesser" comments and more easily find the "gems".

Further, to encourage posting "good" comments, Karma was introduced. "Good" comments earned Karma; "bad" comments lost Karma. Moderation was a mechanism by which Karma could be allocated.

Slashdot experimented with several ways to moderate comments. First, it was just the staff who could moderate. Soon, there were too many comments to keep up, so a select group of members from the community were tapped and invited to moderate comments. Again, that failed to scale up, so those who had been selected were invited to recommend still other users to moderate. And, again, there were scaling issues.

Solution: make Mod Points available to every registered user in good standing and who indicated in their preferences that they were willing to moderate.

Originally, mod points were handed out randomly and expired after something like 6 hours: "Use 'em or lose 'em".

That had some issues and metamoderation was implemented and introduced — moderate the moderations.

Early Tweaking:
Such was the state of things when SoylentNews started. Well sort of. The code base we started from was not current and the metamoderation code was broken. So much so that the implementation was ripped out of the code. Finally we had a working moderation system on our site. Yay!

That worked okay for a while, but we found ourselves with complaints from many that they wanted to moderate and lacked mod points. Nice problem to have, right? This was combined with many more comments than moderations. It was thought that we needed more mod points made available to the community. So, after unsuccessfully tweaking the mod point allocation algorithm it was decided to just not expire mod points until day's end. Every user in good standing got 5 mod points each morning (00:10 UTC) and lasted until the next day whereupon things were reset and a new back of mode points were allocated.

That helped! But but was not enough.

Mod Bombs:
We started to run into problems with "mod bombs" where one user "A" would apply all 5 of their mod points to downmod one other user "B". So code was written to allow checking for such moderations. Staff could generate a report and find such activity. It was decided that:

If you used ALL of your modpoints to downmod ONE user, that was a modbomb. IOW, 5 downmods bad; 4 downmods were permitted.

For a while, anyone who used all of their mod points to downmod a single user was manually given a "timeout". The first time earned a one month suspension of moderation privileges. A second occurrence earned a six month suspension.

Later, because there were still many more comments than moderations, the number of modpoints each registered user in good standing received was increased to 10 per day. The modbomb threshold was, however, kept the same: 4 downmods was still okay, 5 (or more) downmods to the same user was bad.

A complication arose in that there is no easy way for users to keep track of how many downmods they had made on a user. User "A" may do 3 downmods of user "B" in the morning and then 2 more downmods of user "B" in the afternoon. Unintentional transgression. When you only have 5 mod points it was conceivable that a user could mentally track how many times they downmodded a user in one day. With 10 mod points available each day, that became less reasonable.

So, along with the allocation of 10 modpoints per day (easy) it was intended to have code written that would kick in when processing moderations; when the threshold was exceeded, the excess mods would be automatically rejected. And that is still the intent.

The upshot of that is that when checking for modbombs, we no longer give a "timeout" for 5 downmods against a single user in one day. We just reverse the excess mods. We do take note on repeated excesses and are fully prepared to issue a "timeout" when warranted. (e.g. 8 downmods in one day, or several days in close proximity targeting the same user. This is not done unilaterally but rather a check with other staff for confirmation.)

Minor complication: At this point it is unclear if it would be *possible* to put up an info/warning message to the user noting same... It would be *nice* to do, of course, but having a modal message is, AIUI, problematic. There are some other possibilities, but would require some experimentation and investigation. We are still intending to implement this some day.

Sock Bombs:
There are two cases to consider here. First, the same limits apply, each user "A" is limited to 4 upmods of user "B" in a given day, just like for "modbombs". Second, there some who failed to take the hint that, maybe, they should take a look at what they were posting when they received repeated downmods. So, they created a new ("sock puppet") account and proceeded to upmod their own comments, aka a "sockbomb". Staff have ways to note such behavior based on the IPID and SUBNETID that is recorded with every comment and every moderation. We try to give the benefit of the doubt. But, certain patterns do become apparent and are not tolerated. Upmodding your own comment is grounds for an immediate moderation ban.

Summary:
Our experience is that the current system could stand some refinement, automation of transgression detection and mitigation is in plan (but it will be a while), but for the most part what we have works well in the vast majority of cases. In short, Wheaton's Law [wikipedia.org] still applies: "don't be a dick". Following that seems to work the best for the most. (With apologies to anyone named Richard. =)

Original Submission