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.

ayg wrote:

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

mattbisanz wrote:

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.

J.delanoywiki wrote:

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.

matthew.britton wrote:

Limit raised to 100 last night, apparently.

compwhizii wrote:

(In reply to comment #7)

Limit raised to 100 last night, apparently.

Sweet! :)

According to the API, the limit is 10 / min.

mike.lifeguard+bugs wrote:

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.

mike.lifeguard+bugs wrote:

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.

matthew.britton wrote:

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.

bugs wrote:

(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. ;-))

matthew.britton wrote:

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

mike.lifeguard+bugs wrote:

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

bugs wrote:

(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. :-)

matthew.britton wrote:

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

mike.lifeguard+bugs wrote:

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

ayg wrote:

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