Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Hobbling of users who consistently post low-quality content

Parent

Hobbling of users who consistently post low-quality content

+17
−3

There are, unfortunately, a few users on Codidact who relatively consistently make low-quality contributions. These posts often come in bursts and tend to be downvoted fairly quickly, but that doesn't slow them down.

I propose that Codidact should implement some manner in which to slow down such users. They shouldn't be prevented entirely from posting, but there should be limits in place to ensure that their posts don't drown out other content.

I am posting a self-answer with a suggestion for how this can be done, but alternative suggestions (or arguments why this is a bad idea) are certainly welcome!

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

4 comment threads

It's not possible to meaningfully hobble bad users. You can only hobble new users. (1 comment)
Like the idea. Added some extra steps to your basic proposal to allow for "strictness configuration";... (2 comments)
Perfect is the enemy of good (3 comments)
Downvote!!! it's not because my answers/questions are poorly written (2 comments)
Post
+10
−5

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.

For a final decision, when a user saves a post:

  • First, look at their most recent post of the same type (question, answer, article, ...). If that post has a score >0.5 (that is, is positively received by the community), then allow the new post. (Note that this means that if their most recent post has not yet been voted on at all, the user does not get a free pass.)
  • If their most recent post has a score of 0.5 or lower (negatively or neutrally received by the community, including not yet having been voted on at all), then look at the user's sum of received votes. If that value is 0 or higher, then allow the new post.
  • If the user's sum of received votes is negative, then block creation of the new post unless, since the user's most recent post of the same type, the count of posts by other users is at least the absolute value of the user's sum of received votes. (So if a user's sum of received votes is, say, -3, then at least 3 posts must have been posted by other users.)
    • As an escape hatch to allow users to redeem themselves in a reasonable amount of time, cap the number of posts that must have been posted by other users in the interim at 10.

For clarity's sake, because it seems I wasn't clear enough on this part, these are meant to be applied from top to bottom as listed above until an actual decision point is reached. If one criteria doesn't result in an "allow the post" decision, that fact doesn't mean that the final outcome will necessarily be a "reject the post" decision; it means nothing more and nothing less than that the particular criteria didn't result in an "allow" decision. (And similarly for a "reject" decision.) Only if a criteria results in an actual "accept the post" or "reject the post" decision will that be the outcome without considering later criteria. There is no falling through the end of the set of criteria (if there is, that's a bug in this suggestion, so please point it out in a comment); every situation will result in either an "allow the post" or a "reject the post" decision no later than by the time the criteria expressed in the last bullet point has been evaluated.

Looking at the user's most recent previous post as a shortcut means that if a user posts, say, a well-received question, then they can post another question fairly quickly even if they have a previous history of low-quality content, but that after doing so they may (depending on their updated sum of received votes) have to wait for one of their existing posts to be voted on before they can post a third question. This allows a user who has a history of previously having posted low-quality content to, if they put in the effort to write good posts, relatively quickly start working their way back up. Once the user's sum of received votes indicates that their contributions are overall positively received, they will be able to post repeatedly based instead on that record.

Restricting to posts of the same type ensures that for example self-answers aren't hobbled just because they are self-answers to a not-yet-voted-on question.

We might want to look only at the sum of received votes for posts of the same type, or the sum of received votes for posts over a limited time period, or the sum of received votes for the user's most recent some number of posts, but I'm not sure how reasonable any of that would be from a performance point of view. Also, the total sum of received votes is already readily available in the UI, so it's something the user can look at and, knowing the criteria, can predict the effect of. If considering all posts by a user turns out to have unintended side effects, it may be worth considering some variation along these lines.

For UX reasons it might well make sense to also evaluate these criteria early, but the ultimate decision needs to be made by the time the post is saved because we can't know that the client is well-behaved.

Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, interim post count cap 10, possible number of past posts considered) should be configurable per community and possibly even per category (it makes sense to allow more controversial content in the Meta category, for example, since hashing out policies will by its very nature involve making suggestions that some people disagree with), but the values I mention above seem to me like a reasonable starting point that should work reasonably well for low-traffic and higher-traffic communities alike.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

4 comment threads

Disagree on several accounts (9 comments)
“because we can't know that the client is well-behaved.” In other words, guilty until proven innocent... (3 comments)
Should look at more than just most recent post. (2 comments)
I agree (1 comment)
I agree
Lundin‭ wrote about 3 years ago

I agree because it is obvious that down votes isn't getting to them. "Everyone down votes everything I post on any site, so everyone else must be wrong". Nobody seem to stop and consider why they are repeatedly getting down voted over and over. At this point it doesn't seem to work as a way of moderating any of the sites, because we have too little traffic, so the bad stuff does, as you say drown out everything else. This in turn makes other users hesitant to use that site because all the see is down voted crap. So it is actively harmful: what if we lose 5 good users at the cost of keeping this 1 bad apple around.