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 moderator attention?
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
+3
−2

This is a proposal for a refinement of Canina's proposal, or any proposal substantially like it, in response to one of celtschk's objections in the comments.

Canina assumed, and I agree, that the software should execute an algorithm when a post is submitted, using as input any of the data available at the time, with the output determining whether or not the post is allowed at that time. The software could also use the same algorithm to preemptively disable posting UI for users who would not be allowed to submit. celtschk's objection is that any changes to the inputs of the algorithm between the time that a user starts writing a post and the time that the post is submitted could cause a post to get rejected, and that the experience of seemingly being allowed to write a post but then having it be rejected due to causes outside one's control is an unnecessarily demoralizing one, to be avoided.

My proposal is to use an additional bit in the database for each user to store whether a user is currently being ‘hobbled’. The ‘hobbled bit’, or ‘hobbit’ if I may, is checked before a page render to determine whether to disable posting UI, and also checked when a submission is posted to determine whether to allow the post. When a post is allowed, the software additionally executes whatever underlying algorithm is used to determine if a user is allowed to post, on all the data available at the time. If the algorithm yields a negative result, the hobbit is set, and a notice is displayed to the user that subsequent posts won't be accepted until the community sees more activity, or whatever message is appropriate given the underlying algorithm.

A user's own post would be the only way to set their hobbit, so there is no concern about some action outside the user's control causing the user's work to be discarded. The only way for a user to submit a post that would be rejected, assuming normal use of the UI, would be to start two posts in parallel, submit one, ignore the notice that would be displayed after the submission is accepted, and then submit the other.

(Note that the hobbit is not a mutex and is not client-side or connected to session state or cookies; if a user starts writing a post and then closes the tab, their hobbit is not affected nor are any other post drafts in any other tabs. Only submitting a post can set the hobbit, and it is set server-side, checked by any subsequent GETs or POSTs.)

Hobbits should be reset once the underlying algorithm no longer forbids posts, based on time, votes, other user activity, or whatever else the algorithm takes as an input. Implementation of the reset depends on the specific algorithm chosen and on performance concerns; I would think it'd be acceptable to only reset hobbits hourly or even daily, if it came to that. Again, this functionality would only affect set hobbits; the only way to change a user's hobbit from unset to set should be for that user to submit an accepted post, while failing to meet the criteria specified in the algorithm.

Some final notes: throughout, I talk about one hobbit per user, but if the algorithm is written (as Canina's is currently) to consider different post types differently, there would be a hobbit for each post type per user, or a hobbit for each post type and category per user, or however many hobbits are logically needed. Also, if it would make sense to implement hobbits as abilities that are granted and revoked instead of a custom bit (or bitset) column, that might have advantages—I don't really know enough about the ability system to say.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

That suggestion indeed addresses my objections. (1 comment)
That suggestion indeed addresses my objections.
celtschk‭ wrote over 2 years ago

That suggestion indeed addresses my objections.