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.

Post History

63%

+10 −5

Q&A Hobbling of users who consistently post low-quality content

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 ...

posted 2y ago by Canina‭ · edited 2y ago by Canina‭

Answer

#4: Post edited by

Canina‭ · 2021-10-06T07:11:40Z (over 2 years ago)

Copy Link

Raw

Markdown

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.
~~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.
Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.
Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

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.

#3: Post edited by

Canina‭ · 2021-10-05T18:12:22Z (over 2 years ago)

Copy Link

Raw

Markdown

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.
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* a minimum of the absolute value of the user's sum of received votes has been posted by other users since this user's most recent post of the same type.
* As an escape hatch to allow users to redeem themselves in a reasonable amount of time, cap that number of posts that must have been posted by other users 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.
Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.
Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.
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.
Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.
Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

#2: Post edited by

Canina‭ · 2021-10-05T17:29:48Z (over 2 years ago)

Copy Link

Raw

Markdown

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.
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* a minimum of the absolute value of the user's sum of received votes has been posted by other users since this user's most recent post of the same type.
* As an escape hatch to allow users to redeem themselves in a reasonable amount of time, cap that number of posts that must have been posted by other users at 10.
Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.
Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

This is my suggestion for how to implement hobbling of users who consistently post low-quality content.
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* a minimum of the absolute value of the user's sum of received votes has been posted by other users since this user's most recent post of the same type.
* As an escape hatch to allow users to redeem themselves in a reasonable amount of time, cap that number of posts that must have been posted by other users 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.
Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.
Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

#1: Initial revision by

Canina‭ · 2021-10-05T09:59:11Z (over 2 years ago)

Copy Link

Raw

Markdown

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

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* a minimum of the absolute value of the user's sum of received votes has been posted by other users since this user's most recent post of the same type.
   * As an escape hatch to allow users to redeem themselves in a reasonable amount of time, cap that number of posts that must have been posted by other users at 10.

Restricting this 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, but I'm not sure how reasonable that'll be from a performance point of view. If looking at all posts by a user turns out to have unintended side effects, that may be worth considering.

Ideally, the thresholds (vote score threshold 0.5, sum of received votes threshold 0, post count cap 10) 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 definition involve making suggestions that 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.

Communities

Post History