Last modified: 2008-11-18 16:07:20 UTC
Currently members of the rollbacker group on the English Wikipedia are limited to 5 rollbacks per minute, presumably to prevent abuse. Unfortunately, this rate really isn't high enough, and is regularly exceeded while trying to deal with vandalism on the English Wikipedia during busy periods. I could understand such a limit being necessary if rollback was available to all autoconfirmed users, but since it is given out on the English Wikipedia only to individual users at the discretion of administrators, and can be removed again at the first sign of misuse, the potential for abuse seems much lower. It would be nice if the limit could be raised to a level where it does not interfere with its legitimate use by the group of people which it is intended to benefit. Doubling the limit to 10 edits per minute, or doing away with it altogether, would achieve this.
I would support any increase to 10 or above (perhaps to no limit). I frequently hit the 5 rev/min cap while reverting vandalism using Huggle when vandalism rates are high, and it greatly slows down the process.
See discussion on this issue at [[Wikipedia:Village pump (technical)#Non-admin rollbackers]]. Also changed the title to more accurately reflect the wishes here and at VPT.
There's no sane reason to have any limit at all given that any sysop can revoke the status at will.
New discussion at [[Wikipedia:Village pump (proposals)#Non-admin rollbackers]].
It would appear that there is no significant opposition to the idea (Note:I supported it so I'm biased). So I guess now it would be up to the developers having the time to code the solution, test it, and roll it out.
The straw poll at [[WP:VPR#Straw Poll c]] indicated that there was no opposition whatsoever to at least upping the limit and nearly all participants supported removing the limit entirely.
Limit raised to 100 last night, apparently.
(In reply to comment #7) > Limit raised to 100 last night, apparently. > Sweet! :)
According to the API, the limit is 10 / min.
en.wikibooks had 20/min at one point, and the general feeling was this was too low still, so 10/min is really not ok. Removing the rate limit for wikis where rollback is explicitly granted seems reasonable. (Are there wikis where you get it on autoconfirmed or something?) If we're choosing who to allow access to the tool, then the rate limit seems redundant.
On noc I currently see: // For expanded rollback permissions... 'rollback' => array( 'user' => array( 10, 60 ), // was array( 5, 60 ), -- brino 2008-05-15 'newbie' => array( 5, 120 ), // practicality has won out over paranoia on enwiki, raising from 20 to 100 -- TS 2008-05-21 'rollbacker' => array( 100, 60 ), However, for wikis giving +rollback explicitly (enwikibooks for example) no rate limit for rollbackers would be better - we're choosing them to make good use of the tool not giving it out willy nilly.
Resolving this since my original request has been fulfilled and while not infinite, 100 actions per minute is sufficiently high that realistically nobody will be affected by it.
(In reply to comment #11) > On noc I currently see: IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim said that one... but don't quote him. ;-))
(In reply to comment #13) > IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim > said that one... but don't quote him. ;-)) http://noc.wikimedia.org/conf/ "The files are dynamically generated and are perfectly up-to-date." seems to answer that. It could be lying, but I found a "2008-10-06" timestamp in one of the files, so it can't be that out of date.
(In reply to comment #13) > (In reply to comment #11) > > On noc I currently see: > > IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim > said that one... but don't quote him. ;-)) > noc gives live files now, IIRC (In reply to comment #12) > Resolving this since my original request has been fulfilled and while not > infinite, 100 actions per minute is sufficiently high that realistically nobody > will be affected by it. > I was affected by this limit regularly until noratelimit was added to the global rollback group; this is still a problem for those who have non-admin rollback locally, so I'm re-opening this. That said, I'm open to the suggestion that this should be determined on a per-wiki basis, in which case I'll submit configuration requests to replace this.
(In reply to comment #14) > (In reply to comment #13) > > IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim > > said that one... but don't quote him. ;-)) > > http://noc.wikimedia.org/conf/ > > "The files are dynamically generated and are perfectly up-to-date." seems to > answer that. It could be lying, but I found a "2008-10-06" timestamp in one of > the files, so it can't be that out of date. > That shows how long it's been since I've been on noc. :-)
(In reply to comment #15) > I was affected by this limit regularly until noratelimit was added to the > global rollback group. You can read diffs and verify that they do indeed need to be reverted at a rate of more than 100 per minute? Where do we apply to have you do full time recent changes patrol on en.wikipedia, you would make everyone else obsolete.
(In reply to comment #17) > (In reply to comment #15) > > I was affected by this limit regularly until noratelimit was added to the > > global rollback group. > > You can read diffs and verify that they do indeed need to be reverted at a rate > of more than 100 per minute? Rolling back lots of revisions at once can actually be useful when a vandal mass-vandalizes stuff.
(In reply to comment #17) > (In reply to comment #15) > > I was affected by this limit regularly until noratelimit was added to the > > global rollback group. > > You can read diffs and verify that they do indeed need to be reverted at a rate > of more than 100 per minute? Where do we apply to have you do full time recent > changes patrol on en.wikipedia, you would make everyone else obsolete. > Gurch, there's no need to be rude. Regardless, flood vandalism is common on small wikis. Luckily I'm no longer affected by this rate limit there. Nonetheless, one would think solving this for local rollback groups would make sense. If this particular bug isn't going to get addressed, it should be closed again, and I will make a configuration request for my home wiki separately.
I think there's some confusion here. The limit was allegedly raised to 100 / min, but either the API is misreporting the limits or the rollback right is ignoring the configuration line. For somebody in the rollbacker group on en.wiki as of today, this is the result: http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits <ratelimits> <move> <user hits="8" seconds="60" /> </move> <emailuser> <user hits="200" seconds="86400" /> </emailuser> <rollback> <user hits="10" seconds="60" /> </rollback> </ratelimits> That clearly states that 10 rollbacks are allowed every 60 seconds. So there's obviously some type of bug here.
(In reply to comment #20) > I think there's some confusion here. The limit was allegedly raised to 100 / > min, but either the API is misreporting the limits or the rollback right is > ignoring the configuration line. For somebody in the rollbacker group on > en.wiki as of today, this is the result: > > http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits > > <ratelimits> > <move> > <user hits="8" seconds="60" /> > </move> > <emailuser> > <user hits="200" seconds="86400" /> > </emailuser> > <rollback> > <user hits="10" seconds="60" /> > </rollback> > </ratelimits> > > That clearly states that 10 rollbacks are allowed every 60 seconds. So there's > obviously some type of bug here. > Could you verify that the limit actually is higher than 10 rollbacks per minute (e.g. by trying to rollback 20 edits in the same minute)?
Using an autoconfirmed account in the rollbacker group on en.wiki I was able to rollback more than 10 edits in a minute. (See <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.) This indicates that it is the API that is misreporting here. I've removed the shell keyword. I suppose I could / should file a new bug, but meh.
(In reply to comment #22) > Using an autoconfirmed account in the rollbacker group on en.wiki I was able to > rollback more than 10 edits in a minute. (See > <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.) > > This indicates that it is the API that is misreporting here. I've removed the > shell keyword. I suppose I could / should file a new bug, but meh. > I'll look into it.
(In reply to comment #23) > (In reply to comment #22) > > Using an autoconfirmed account in the rollbacker group on en.wiki I was able to > > rollback more than 10 edits in a minute. (See > > <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.) > > > > This indicates that it is the API that is misreporting here. I've removed the > > shell keyword. I suppose I could / should file a new bug, but meh. > > > > I'll look into it. > I did, and it works fine for me: on MW.org I'm a sysop and consequently have no rate limits at all, on enwiki I'm not a sysop and I get the exact same ratelimits listed in comment #20. This leads me to think the reported must've been logged out while querying meta=userinfo. To be sure, please have someone in the rollbacker group (but not in the sysop group!) run the following API query: http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits|groups If the result indicates the user is in the rollbacker group *and* lists the rate limits for anons, please REOPEN.
(In reply to comment #24) > I did, and it works fine for me: on MW.org I'm a sysop and consequently have no > rate limits at all, on enwiki I'm not a sysop and I get the exact same > ratelimits listed in comment #20. This leads me to think the reported must've > been logged out while querying meta=userinfo. To be sure, please have someone > in the rollbacker group (but not in the sysop group!) run the following API > query: > > http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits|groups > > If the result indicates the user is in the rollbacker group *and* lists the > rate limits for anons, please REOPEN. I'm in the rollbacker group but not a sysop on enwiki, and I get 10 rollbacks a second listed: <ratelimits> <move> <user hits="8" seconds="60" /> </move> <emailuser> <user hits="200" seconds="86400" /> </emailuser> <rollback> <user hits="10" seconds="60" /> </rollback> </ratelimits>
Fixed in r43678. Group-specific rate limits were introduced after uiprop=ratelimits was added, and I must've overlooked it.
