Last modified: 2013-10-07 22:53:42 UTC
Suggested setting: same as email. 'emailuser' => array( 'ip' => array( 5, 86400 ), // 5 per day per ip (logged-out and new users) 'newbie' => array( 5, 86400 ), // 5 per day for non-autoconfirmed 'user' => array( 20, 86400 ), // 20 per day for users ), Minimal setting: respect edit ratelimits, 'edit' => array( // 8 ed./min per each non-autoconfirmed, or group thereof from same IP 'ip' => array( 8, 60 ), 'newbie' => array( 8, 60 ), ),
Why not just add a userright, and take away their ability to thank if they troll?
(In reply to comment #1) > Why not just add a userright, and take away their ability to thank if they > troll? Why reinvent the wheel? Just reuse the standard approach, that is rate limiting.
For someone who does hundreds of edits a day is 20 not much. But for someone who is a troll, 20 is already too much. The standard approach is insufficient when a users uses the thanks-button too often. Setting a limit doesn't solve the situation that users mis-use the thanks button too often on wrong places. Setting a userright to take away their ability is something what does work. We already have a case on nl-wiki where a user is trolling with the thanks button, setting a limit on 20 doesn't solve it at all, useless.
More on the rationale: as far as I know, thanks also trigger an email notification by default; hence, the rate limiting for them should equal the rate limiting for emails, for the same reasons. Among other risks, let me mention that sending too many thanks email notifications (which by definition are unsolicited) will get many users e.g. in Gmail mark them as spam, which in turn will send legitimate notifications to the spam folders and trash the whole notification system (bug 52915). So, let's please be careful. Romaine, rate limiting is not magic, it's a harm reduction system. Someone who does thousands of edits a day is 99 % of the cases either a bot or a sysop, so rate limits don't apply. I'll file another bug shortly to address your concern.
When someone abuse the editing system, there's the user blocking mechanism in place, after an optional warning message to the user. This should work the same. User rights are normally used to give more rights, not to revoke rights which weren't manually added in the first place. The rate limit should be in place to solve Nemo concerns about email notifications and log flooding. For users that doesn't reach that limit but still misuse it, the standard block should be sufficient.
No comments in three days: adjusting summary to reflect the current proposal. I'll add "shell" keyword after someone confirms the setting works.
(In reply to comment #6) > No comments in three days: adjusting summary to reflect the current proposal. > I'll add "shell" keyword after someone confirms the setting works. Has discussion for this change taken place somewhere?
(In reply to comment #7) > Has discussion for this change taken place somewhere? What place would you suggest? To me it seems a trivial adjustment, logical consequence of the existing configuration for equivalent actions.
I'm confused. Aren't thanks are already ratelimited? If thank nuking is a thing, it's not something I've seen (other than the one example above).
My 2 cents: * Rate limiting makes sense. Like any action that affects other users, we should not allow a user to massively abuse the system. Like edit rate limit, a rate limit here makes sense. This way a user will only be able to do limited damage. * User right: Not sure, I think any user allowed to edit should be allowed to do thanks. If a user is abusing the system, block them. Revoking a specific user rights is counter-intuitive in our rights system, and besides, if the user is vandalising through thank yous, that user has no business contributing elsewhere if he can't behave. We don't revoke the movepage right or createpage right separately either.
(In reply to comment #9) > I'm confused. Aren't thanks are already ratelimited? If thank nuking is a > thing, it's not something I've seen (other than the one example above). Yes. According to the docs, no one can thank more than 10 users/minute. Personally I think the arbitrary limit of 5 or 20 thanks a day is an unnecessary addition. Unlike email, for which there is a very very high potential for spam and trolling, thanks are a standardized action which has comparatively little potential for negative/abusive use. I think *if* it seems clear the tool is being used at too great a volume by new people, then we should strongly consider making the current rate limit more strict. But there's no reason to add additional limits or micmic the email feature's rate limit, considering how different the feature is. There is similarly no technically-enforced rate limit on how many edits you can revert as a new person, and communities deal with it just fine by imposing looser social limits.
Thanks has always been rate limited. It's even mentioned in the Extension documentation on mediawiki.org. $wgRateLimits += array( 'thanks-notification' => array( 'user' => array( 10, 60 ) ), );
