[?]Too much stress on moderators? - Page 7

On January 17 2009 03:31 Fontong wrote:

Sometimes my stream is minutes ahead of everyone else's. I post the future.

On January 17 2009 05:59 Badjas wrote:

Hello fellow software developer. It is absurd to call my idea daunting to implement. It takes one extra entity, the report, and one extra field in the user table. Then it takes some pages: report page, report confirm page, list reports page (for moderators), report details page (with action buttons, delete post / ban user / cancel reports...). That's about it. Then the functions: reporting is simply adding an entry to a table. OK-ing reports is the action on the user/post, already existing, then there is, for each reporter, give bonus (+ 1 on entity field), and delete report, or mark historic. canceling reports, for each reporter -1 on user, mark report historic. If posts get deleted through other means, and have reports attached to it, then logically the writers of those reports get a bonus automatically. I think that covers it. This is two days of work.

And for your solution: Do you report users directly? If you do report posts, you got the same extra entity. And the presentation of posts is reduced to an aggregation of their writers. If you report users directly, then moderators will have to look for offending posts by themselves, not a good solution. I agree that there is merit to aggregating by writer though, still sorted on scoring, then with a drill-down to the reported posts by that writer.

However, my proposal adds a self-balancing maintenance-free score to reports, at very little cost of implementation. And then there's some perks, like one could sort users on their (negative) reporting habits, and warn them for trolling with reports. Perhaps take away reporting options for those with a score of -20 or lower (they won't have a means to get it back without moderator intervention, if the user admin page will include this new score field.)

On January 17 2009 12:04 onepost wrote:

*cough* *cough* are you kidding? You needed a huge paragraph just to list the features! Even if you wrote this quick and dirty in VB it might take you longer than that.
Plus, everything is way more complicated when it's on the web...

On January 17 2009 12:04 onepost wrote:

No you don't report users but posts. However a database request (SQL?) to gather posts matching a requirement (flag) is trivial, and then it's just aggregating by user and sorting by count. There's already something like this implemented elsewhere (see your own posts lists, for example) so I assume it would be trivial, just copy-paste then tweak.

On January 17 2009 12:04 onepost wrote:

It's already been suggested (and essentially agreed upon) that abusing the abuse report function could result in ban, which is much more simple. Honestly I don't like overly-complex Slashdot-like algorithms that attempt to substitute themselves to the good judgement of the admins, especially since TL will never grow nearly as large as Slashdot.

On January 17 2009 12:04 onepost wrote:
With all due respect, I don't like your idea at all, and I'm sure TL's coders wouldn't either...

On January 17 2009 18:49 Badjas wrote:

So you suggest a single flag on the post entity will suffice? Perhaps even a counter..

Sure, abusing reports could result in a ban. Neither your solution nor mine has anything like automatic banning, so where is your added simplicity? As a matter of fact, your solution will actually not help admins see which users are abusing the reporting functionality since there is no way to trace which user has reported which post. It's lacking that entity that I told you you'd need., whereas my solution has a feature to automatically, without moderator intervention, take away reporting rights from those that abuse it.

Now here come the overly complex slashdot like algorithms:
Assuming the user table has a field ReportingScore
Assuming there is a PostReport entity with the following fields:
UserId
PostId
Remark (optional)
Timestamp
State (actual, processed)

// On the forum page, extra code:
If User.ReportingScore > -5 // can be tweaked.
and Post.Timestamp > Today - 40 // to be tweaked, let's not let old posts be reported
Show report post button
end if

// Report post page:
A simple form, displaying original post with a remarks entry box and an ok / cancel button. No algorithms other than 'add row to PostReport entity'
(with additional check if logged in user has an ok ReportingScore)

// Post report confirm page: duh

// Reported users page:
select PostUser.Name, sum(User.ReportingScore) Score,
from PostReport, User, Post, User PostUser
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and Post.UserId = PostUser.UserId
and PostReport.State = actual
and PostReport.TimeStamp > Today - 10
and User.ReportingScore > 0
group by PostUser.Name
order by Score Desc
//
Display each record, plain and simple, and offer drilldown to a ReportedPostsPerUser page

// Reported posts per user
select PostId, sum(User.ReportingScore) Score,
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and PostReport.TimeStamp > Today - 10
and User.ReportingScore > 0
and Post.UserId = "page parameter's user id"
group by PostId
order by Score Desc
//
Display the posts with additional existing queries.
The page could offer an option to ban the user and delete the post in one fell swoop. That would then go along the lines of:

// Fast-ban user:
select whatever
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and Post.UserId = "page parameter's user id"
//
foreach row
update user table, increase ReportingScore by one
if post not deleted, or --nuked--, do so
update report set state = processed
end foreach
// Deal with user still with existing methods

// Reported post details page
select PostReport.Remarks, User.Name, User.ReportingScore,
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and Post.PostId = "page parameter's post id"
order by User.ReportingScore Desc
//
display post
foreach row
display User.Name, User.ReportingScore, PostReport.Remarks
end foreach
Display buttons: .. let's see.. temp-ban-user, ban-user. nuke-post. no-action-but-reports-good, no-action-reports-bad.
All buttons but the last one end up with an already existing action, and the 'good reports algorithm'. The last button triggers the 'bad reports algorithm'.

// Good reports
select PostReport
from PostReport
where PostReport.PostId = "page parameter's post id"
//
foreach row
increase user's ReportingScore by 1
update PostReport set state = Processed
end foreach

// Bad reports
select PostReport
from PostReport
where PostReport.PostId = "page parameter's post id"
//
foreach row
decrease user's ReportingScore by 1 // or 2... heheh!
update PostReport set state = Processed
end foreach
//
//and take that extra action depending on which button is pushed

// Top/bottom reporting users
select top 10 User.Name, User.ReportingScore // or bottom 10
from User
order by User.ReportingScore
//
display rows

That about sums it all up. I wrote it in one stretch over the course of one and half hour (dealing with playing kids around here..) There's some extra thought put in the usability here and there that I am not bothering to detail now. Oh yeah, I could have made errors.. pseudocode is so hard to debug. Oh and if you could point out the overly complex slashdot-like algorithms, that would be dandy.



I wouldn't be so sure about that.. Look at the above pseudocode. 90% of it is already required for implementing your idea, my additional feature is 10% of the code. (no I didn't actually count, but in terms of implementation time, that's my overly negative estimate. Yes I am a programmer, I am trained to make negative estimates ;-) )

On January 18 2009 02:14 Chill wrote:
Can we step back and look at this. Do we really need to code this elaborate feedback system? If you want to pseudomoderate, just PM a moderator.