Page MenuHomePhabricator

Rollback on en.wiki
Closed, ResolvedPublic

Description

Please enable Rollback permissions that are granted by b-crats on en.wikipedia


Version: unspecified
Severity: enhancement

Details

Reference
bz12534

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:01 PM
bzimport set Reference to bz12534.
bzimport added a subscriber: Unknown Object (MLST).

...is there a page where consensus exists for this?

cannon.danielc wrote:

... nope. Apparently this bug is just for tracking purposes in case enwiki decides it wants this.

En.wiki has been debating this issue for about a week, see http://en.wikipedia.org/wiki/Wikipedia:Non-administrator_rollback . 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.

ais523 wrote:

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.

Ryanpostlethwaite wrote:

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.

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.

matthew.britton wrote:

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.

jc37_friends wrote:

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

Is $wgRateLimits['rollback'] set?

ayg wrote:

<TimStarling> yes
<TimStarling> 'rollback' => array(
<TimStarling> 'user' => array( 5, 60 ),
<TimStarling> 'newbie' => array( 5, 120 ),
<TimStarling> ),

Ah, that is a decent limit, for some reason I was thinking it was much more restricted.

ayg wrote:

(also note that sysop, bureaucrat, and bot groups are excluded from all rate limits)

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?

GiveRollback.php

$wgGroupPermissions['sysop']['giverollback'] = true;

ayg wrote:

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.

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

matthew.britton wrote:

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.