Last modified: 2008-01-14 17:46:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12534 - Rollback on
Rollback on
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
Depends on:
  Show dependency treegraph
Reported: 2008-01-07 05:28 UTC by Betacommand
Modified: 2008-01-14 17:46 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Betacommand 2008-01-07 05:28:36 UTC
Please enable Rollback permissions that are granted by b-crats on en.wikipedia
Comment 1 Aaron Schulz 2008-01-07 05:30:03 UTC there a page where consensus exists for this?
Comment 2 Daniel Cannon (AmiDaniel) 2008-01-07 05:38:43 UTC
... nope. Apparently this bug is just for tracking purposes in case enwiki decides it wants this.
Comment 3 MZMcBride 2008-01-07 05:45:48 UTC has been debating this issue for about a week, see . It comes down to this: the vote is pretty much locked at 67% in support. Sysadmins want to be able to point to on-wiki consensus before making changes like this, however, no one's really sure if 67% is consensus or not.
Comment 4 ais523 2008-01-07 11:21:18 UTC
Note that the request on the page referenced in comment 3 is actually for admins to be able to grant/revoke rollback, rather than just bureaucrats. It's somewhat unclear if there is consensus on the linked page or not, though, and users are still actively voting; it's probably worth waiting to see what happens there before making this change.
Comment 5 Ryan Postlethwaite 2008-01-08 12:51:50 UTC
The poll has now closed with 304 supports and around 150 opposes. I'd say that's consensus, but please take a look. It should clearly be noted that there was consensus for admins to grant the permission, not the crats and this is really unworkable.
Comment 6 Alex Z. 2008-01-08 20:47:25 UTC
Also, since this is to be assigned on an individual basis, the possibility for abuse is minimized and the rollback group should be excluded from the rate limiter either with $wgRateLimitsExcludedGroups or another method if it is possible to exclude them only from the rollback limit.
Comment 7 JeLuF 2008-01-09 22:53:17 UTC
Comment 8 Gurch 2008-01-10 03:41:44 UTC
Lack of communication between developers and the community is never a good thing. As anyone reading this alreay knows, a handful of contributors to the English Wikipedia are getting really worked up about this. I personally welcome the change, but my opinion means little. Devs may wish to go back on themselves here. Or not, of course.
Comment 9 jc 2008-01-10 04:24:22 UTC
If you were to at least change the implementation to what was requested at the top (That bureaucrats grant/remove) then I think at least ''some'' of the concern would be removed (mine, at least), and would allow for further discussion of whether administrators should grant/remove (and whether there should be an edit summary - aka Tim Starling's "two-click" suggestion).
Comment 10 Aaron Schulz 2008-01-10 04:33:23 UTC
Is $wgRateLimits['rollback'] set?
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-10 04:36:49 UTC
<TimStarling> yes
<TimStarling>         'rollback' => array(
<TimStarling>             'user' => array( 5, 60 ),
<TimStarling>             'newbie' => array( 5, 120 ),
<TimStarling>         ),
Comment 12 Alex Z. 2008-01-10 05:34:44 UTC
Ah, that is a decent limit, for some reason I was thinking it was much more restricted.
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-10 19:16:06 UTC
(also note that sysop, bureaucrat, and bot groups are excluded from all rate limits)
Comment 14 Shinjiman 2008-01-11 13:57:44 UTC
Isn't the "GiveRollback" extension provides a better functionality to implementing the rollback permission?

If a normal sysop would give the rollback permission to a non-sysop user, isn't better to add the stuff below to the extension?


$wgGroupPermissions['sysop']['giverollback'] = true;
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-11 17:34:08 UTC
No.  Extensions such as GiveRollback, Makesysop, and Makebot are obsolescent with the new unified Userrights interface.  Makesysop and Makebot will be disabled when the Userrights interface is cleaned up a little.
Comment 16 Alex Z. 2008-01-11 21:16:55 UTC
And I think the only real difference is that the extension uses a separate log rather than the user rights log. I believe Brion's response when asked if we should use that (a few months ago) was that it would be "silly."
Comment 17 Gurch 2008-01-14 17:46:34 UTC
Putting this back to FIXED. The drama over at en.wikipedia seems to have died down, the feature is still enabled and it seems that it will remain so for now. Further discussion on the matter is best done somewhere more visible than here. In the event that consensus does change, any reversal of this is probably best handled as a separate bug.

Note You need to log in before you can comment on or make changes to this bug.