Misplaced Pages

talk:Rollback/Archive A - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Rollback

This is an old revision of this page, as edited by Mehran (talk | contribs) at 07:47, 5 February 2015 (→Oppose). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 07:47, 5 February 2015 by Mehran (talk | contribs) (→Oppose)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following list: When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Should rollback be changed from a user right to a gadget? 21:24, 1 February 2015 (UTC)

Background

Rollback is a tool which allows for the easy reversion of vandalism to Misplaced Pages. Originally it was part of the administrator's toolset. The community eventually concluded that it should be made available to non-admin users and it became a user right that anyone could apply for at request for permisssions.

Developments in automated tools since that time appear to have changed the situation and therefore a review of how users gain access to this tool seems in order.

Rollback-related tools

  • Twinkle is a multi-function automated editing tool with what is arguably an improved version of the rollback tool embedded in it. No permission is required to use it, any autoconfirmed account may switch it on for themselves in their preferences.
  • Other automated tools such as Huggle and STiki require the user to already have the rollback user right before they may use them. Because of this many requests for the permission are from users who are simply trying to access other tools, and the admins who review these requests have become the unwilling gatekeepers for these tools.

Rationale for review

  • Rollback is actually no more "powerful" than the undo function, it is just considered easier to use.
  • There is literally nothing a user with rollback can do that a user that does not have rollback cannot do using non-automated editing
  • The value of using administrative resources to review requests for a very low-level tool is questionable, especially when one considers that Twinkle access is granted to all users automatically and technically cannot be revoked.
  • Twinkle does not work with some web browsers. Therefore, some users cannot use it for rollback and must ask permisssion for a tool that other users are essentially granted automatically.
  • Conversely, administrators are given this tool by default and actually cannot turn it off if they wish to.

Proposal

Rollback is to be considered a gadget, like Twinkle, instead of a user right. Misplaced Pages:Requests for permissions/Rollback will be closed and marked as historical, and rollback will be added to the "gadgets" section in user preferences. Any registered user may turn it on or off at their discretion. It will no longer be bundled with administrative rights but instead will be optional for all registered users. At its discretion the community may impose new screening processes for tools that previously relied on rollback permisssion to prescreen applicants.

Support

  1. As proposer. Rollback is an extremely low-level tool and should not be restricted. Tool developers and maintainers can develop their own standards to restrict access, I don't believe that is what the community intended when this was originally unbundled form the admin toolkit. It's time to admit that this is actually a pretty weak tool that is not particualry dangerous, especially in light of the fact that twinkle is available to one and all without having to ask. Beeblebrox (talk) 21:37, 1 February 2015 (UTC)
  2. Support, given that Rollback is the only existing user right where its function can be accomplished without actually having the right. I mean, before I had rollback, I performed my own "rollbacks" by viewing an old version of an article/page, saving a dummy edit with it, and then, the page is reverted to that version. (I might be violating WP:BEANS here, but I'm doing so to illustrate a point.) Rollback is redundant, and not having it isn't going to prevent vandals from performing rollbacks. And, in all honesty, I'd rather Rollback be a gadget ... so that I can disable it for myself; I lost count of how many times I have accidentally performed a rollback due to a misplaced mouse click. Steel1943 (talk) 22:15, 1 February 2015 (UTC)
    Alternately, if consensus does not exist to convert rollback to a gadget, I also support it being removed altogether. Steel1943 (talk) 08:59, 2 February 2015 (UTC)
    If it was removed altogether, it would break Huggle and other tools that rely on it. Squinge (talk) 09:45, 2 February 2015 (UTC)
    @Steel1943: Also, "To revert consecutive edits more quickly, you can compare last good and last bad versions and then click "Undo"", to quote some advice I was given on my talk page. Squinge (talk) 09:56, 2 February 2015 (UTC)
  3. Support as long as anonymous users can't use it. Richard75 (talk) 23:00, 1 February 2015 (UTC)
  4. Support This seems logical and I agree with the proposer's rationale. Everymorning talk 23:10, 1 February 2015 (UTC)
  5. Support as there has been no need for this group for a very long time. — {{U|Technical 13}} 23:19, 1 February 2015 (UTC)
  6. Support, rollback should be made available to auto-confirmed users. This is how it should have been done back when rollback was originally devolved from the administrator kit. Instead we got some silly bureaucracy. The damage that can be inflicted with rollback is less than the damage that can be inflicted with normal editing. Antrocent (♫♬) 23:34, 1 February 2015 (UTC)
  7. Support. Autoconfirmed users already have automatic access to Twinkle, which can cause more damage than rollback if you know some its more dangerous features, so I don't see any reason to oppose this. --Biblioworm 00:05, 2 February 2015 (UTC)
  8. Support per Steel1943 comment. IPadPerson (talk) 00:25, 2 February 2015 (UTC)
  9. Support - It's very useful for reverting multiple edits, whether it's vandalism or not, especially when editing from mobile devices. I think restricting its use was always a bit shortsighted, as all rolled-back reverts can be undone just as easily as a multi-edit reverts. - BilCat (talk) 00:33, 2 February 2015 (UTC)
  10. Support Personally for my first 500 edits I did vandalism patrol to understand how Misplaced Pages worked. After I got 500 edits I requested the userright for this tool and was able to do vandalism control much better. I always wondered why this tool was restricted because I could not see how it could be used inappropriately to greater effect than other naughty things people could do. Blue Rasberry (talk) 00:54, 2 February 2015 (UTC)
  11. Support, I don't see a problem with this, as Twinkle has it's own Rollback feature. VegasCasinoKid (talk) 01:24, 2 February 2015 (UTC)
  12. Support Any user who can completely blank a page on a mouse click should certainly be able to revert to a certain edit. Marteau (talk) 03:57, 2 February 2015 (UTC)
  13. Support Autoconfirmed users can rollback articles to previous versions using tools like Twinkle. Rollback permission is not necessary to users who use twinkle as it has it's own Rollback feature which doesn't require Rollback permission. So I personally think Rollback user right is not quite useful.--Chamith (talk) 06:15, 2 February 2015 (UTC)
  14. Support. I see no reason to restrict a tool that doesn't actually do anything that can't be done without it. And I really don't understand the terror that the suggestion seems to have struck in the hearts of so many opponents. Squinge (talk) 09:44, 2 February 2015 (UTC)
    • Thinking further, I obviously wasn't around at the time, but I get the feeling that Rollback was introduced back when the only alternative was single-edit Undo (please do correct me if I'm wrong), and it was intended for vandalism-only reverts without an edit summary. Maybe server power was a lot less back than, and maybe the extra speed made a difference too, I don't know. But these days, Undo can undo multiple edits in one go, just the same as Rollback, and Twinkle can also do it without needing the Rollback right. And in user-interface terms, there's no appreciable difference in speed. Rollback really doesn't seem to be anything special any more. Squinge (talk) 14:44, 2 February 2015 (UTC)
    • Actually, Undo appears to be more powerful than Rollback! Undo will revert to any previous version, reverting edits by multiple users, while Rollback will only revert consecutive edits by the same user. Squinge (talk) 14:47, 2 February 2015 (UTC)
  15. Support, as Squinge and other have said. This is not a power, it's just a minor convenient time-saving device. There exist actual powers (e.g. ability to rename articles, to blank pages, to run ("semi-")automated scripts against thousands of articles) that automatically accrue to all users or to autoconfirmed users. Rollback is nothing in comparison. If people are wont to do reverts without edit summaries, they will do it anyway using "undo" or other means. W. P. Uzer (talk) 11:40, 2 February 2015 (UTC)
  16. Weak Support BUT we need to involve the creators of STiki, its only requirement is to have Rollback rights. And there may be others that use this standard too. EoRdE6 14:30, 2 February 2015 (UTC)
    supportmight be a good idea--Regisaurusjacobi 15:01, 2 February 2015 (UTC) Vandal comment struck. Epic Genius (talk) 19:32, 3 February 2015 (UTC)
  17. Weak Support Adding Rollback as an option under Gadgets is a great idea. But there should kick hook on removing the ability if it gets misused/abused. -Fnlayson (talk) 15:09, 2 February 2015 (UTC)
  18. Support. With Twinkle, the horse is already out of the barn. There is no longer any good reason to make rollback a special right. Rollback should be allowed for autoconfirmed users. Binksternet (talk) 15:29, 2 February 2015 (UTC)
  19. Strong support, per proposer. APerson (talk!) 15:47, 2 February 2015 (UTC)
  20. Weak support similar to Antrocent and Biblioworm. Twinkle can already rollback, and an easy way to rollback anyway is to edit the version of the page for restoration (this is used by popups). Also, making this a gadget would make it as obvious as Twinkle, except with a more obvious name. —George8211 / T 19:22, 2 February 2015 (UTC)
    You don't even need to edit the restoration version - just diff and click Undo! Squinge (talk) 19:27, 2 February 2015 (UTC)
    Does that work with reverting multiple edits? —George8211 / T 19:34, 2 February 2015 (UTC)
    Yes, and by multiple users too - give it a go at the sandbox. Squinge (talk) 19:37, 2 February 2015 (UTC)
    Everything you need to know is at Help:Reverting. Rollback was never intended to supplement undo. — MusikAnimal 20:04, 2 February 2015 (UTC)
    I've downgraded my support to weak support as I've seen some comments about the ease of using rollback. —George8211 / T 20:36, 2 February 2015 (UTC)
  21. Support. Rollback is a convenient and useful tool that should be available to autoconfirmed users. Omo Obatalá 03:47, 3 February 2015 (UTC)
  22. Support: Oh for pity's sake. Did the Oppose voters miss the bus, and not recognize the plain fact (which is stated in the proposal) that every single autoconfirmed editor has access to rollback already, by virtue of having unfettered access to Twinkle? This just acknowledges the facts on the ground. Ravenswing 06:39, 3 February 2015 (UTC)
    If you had read my !vote, you would have realised that I agree this is somewhat true; you however are failing to draw a distinction between Twinkle rollback (which by default requests and edit summary and is slower) and real rollback (which grants access to eg Huggle). Please don't present oppose !voters as idiots when we have expressed our understanding of your point already. BethNaught (talk) 07:22, 3 February 2015 (UTC)
  23. Support. Current situation is silly. – Smyth\ 11:40, 3 February 2015 (UTC)
  24. Support - Readily available scripts exist that are almost as fast and in some ways more powerful than conventional rollback. There are lot of things that vandals hypothetically could do. Anyone with a decent amount of coding knowledge could write a program that could vandalize up to 8 pages per minute (the software rate limit) using one of the dozen or so publicly available bot frameworks. Virtually no one actually does, just like virtually no one takes the time to get autoconfirmed just so they can go around reverting people with Twinkle. As long as users have to actually take an action to enable it, that should be sufficient to avoid most cases of misuse from poor knowledge. Mr.Z-man 18:29, 3 February 2015 (UTC)
  25. Support: You can easily rollback by editing a previous version of a page. This might not be as quick or as obvious, but still can be done. Eman235/talk 18:32, 3 February 2015 (UTC)
    As I keep pointing out, you do not even need to edit a previous version of a page, you just need to do a diff and then use Undo. Squinge (talk) 18:35, 3 February 2015 (UTC)
    Fair point! Though, less intuitive. Eman235/talk 19:51, 3 February 2015 (UTC)
  26. Support: Rollback contains only a subset of the functionality that is already available to auto-confirmed users (in the form of Twinkle). Therefore, adding a gadget for rollback (if disabled by default) cannot increase the vandal threat. However, one difference between regular and Twinkle rollback is the ability to use Huggle, STiki, etc. I doubt that the ability to use these tools would contribute to vandalism, because they are vandal fighting tools. Also, I have never seen a vandal that uses Twinkle. CarnivorousBunny 23:51, 3 February 2015 (UTC)
  27. Support. I never quite understood why it was anything special, and W.P. Uzer makes a good point about how this is less powerful than things that don't require user rights. Plus, if we made it a gadget, we administrators would be able to remove it from ourselves if we don't want it. Not an issue for me, since I always use a laptop, but I've seen smartphone-using editors who frequently use rollback by accident and request its removal — if this is the case for an admin, there's nothing we can do about it. If it were a gadget, the admin would be able to turn it off, rather than having to continue watching out for misclicks. Nyttend (talk) 04:40, 4 February 2015 (UTC)
    It's special because it's a native mediawiki feature, much more resilient than gadgets which can be broken due to server issues or messing around in mediawiki namespace, it's much faster, and it gives no word of explanation on how to use it while TW or undo does. It can be hidden, see here. Cenarium (talk) 05:09, 4 February 2015 (UTC)
    By "making rollback a gadget" I don't think Beeblebrox is actually proposing replacing the MediaWiki rollback with a pure JS version, but basically doing the inverse of that link - hiding the link by default, then having a CSS gadget to enable it. Though personally I would rather leave it as a user group that any autoconfirmed user can add/remove from themselves which MW alerady supports. Then it wouldn't require any CSS/JS and admins could completely disable it if they wanted, not just hide it. The only difference is that you would need to use Special:Userrights instead of Special:Preferences. Mr.Z-man 17:14, 4 February 2015 (UTC)
    Oooh, I like that idea. Add self-granting and revoking rollback to autoconfirmed. That would fix everything this RFC addresses, without more javascripts. Courcelles 22:16, 4 February 2015 (UTC)
  28. It's a bit irrelevant when there are more powerful tools available to those who want or can find them. Stifle (talk) 10:35, 4 February 2015 (UTC)

Oppose

  1. Strong oppose There's a reason why we don't do things like giving it to autoconfirmed users by default. It's an abusable right and thus it has to remain a revokable right.--Jasper Deng (talk) 23:25, 1 February 2015 (UTC)
    What exactly are we revoking if the function can be done without the tool/gadget? Steel1943 (talk) 23:33, 1 February 2015 (UTC)
    Rollback is more than just a quick way to revert. It is important to note that Huggle access is contingent upon having access to rollback, after all. There is also a very good reason why global rollback has a pass rate less than 50%.--Jasper Deng (talk) 01:05, 2 February 2015 (UTC)
    Errr ... have you noticed that autoconfirmed users, just by virtue of deciding to use Twinkle, have access to the tool already? Whether rollback is any more an abusable right than other tools is arguable, but the ship's already sailed. Ravenswing 06:43, 3 February 2015 (UTC)
    No, Twinkle is less powerful on a technical level. See some of the other comments below. Also, Twinkle's edit summaries are more descriptive than rollback's. Again, rollback also provides access to other software such as Huggle.--Jasper Deng (talk) 06:50, 3 February 2015 (UTC)
    There will most likely be an example someone knows about, but I have never personally seen Twinkle be abused blatantly by a vandal. Currently the vandalism caused by abuse of Rollback/Twinkle is negligible (as far as I can tell). I am worried about the fact that Rollback, technically speaking, is a lot more powerful than Twinkle (think about someone achieving auto-confirmed and then running a script that rollsback thousands of pages before being blocked). I would definitely support an edits/minute limit, one that is not low enough to be reached by human editing, but enough to limit the effects of vandal scripts. Like blatant abuse of Twinkle, I have never personally seen vandal caused by scripts, but it is a real threat if rollback is the right of every autoconfirmed user. I would also support disabling the gadget by default. In general, I think that the help this will give to users in fighting vandalism will far outweigh the effects of the use of the tool by vandals. CarnivorousBunny 23:58, 4 February 2015 (UTC)
  2. Strong oppose removing mediawiki rollback from admin toolset. Especially if this is going to rely on javascript, as almost all gadgets do, but even if not. It should not be required from administrators to use a javascript-based gadget to rollback, not just for their sake, but for the site's sake. Admins can already hide rollback links if they want, so not wanting it is not an issue. But on grounds of site security, making admin rollback a gadget would be extremely inadvisable, it's much safer to rely on native mediawiki rollback. Should I remind you that only a few weeks ago, we had almost all gadgets failing. Cenarium (talk) 01:48, 2 February 2015 (UTC)
    In addition, I would argue that if it turned out to be necessary, it's a case where devs should override any community decision based on site security grounds. As for removing the rollback usergroup, it would depend on whether we have enough admins to handle vandalism in the event of such an emergency, but in my opinion we do not, so I would keep the usergroup, although it may be made smaller, with different criteria for granting, and we could advertise use of the gadget as the preferred alternative. Cenarium (talk) 01:59, 2 February 2015 (UTC)
    Also noting that I would also oppose on grounds of insufficient safeguards against misuse (not abuse), as per this reply. Cenarium (talk) 20:05, 2 February 2015 (UTC)
  3. Oppose I agree with MusikAnimal, whose comment is below. The little bit of extra time it may take to review and decide upon a request for permission will be less than the time it takes to patrol and undo the vandalism by misguided editors who have gotten the permission. CorinneSD (talk) 01:50, 2 February 2015 (UTC)
    I've heard this now from a few people, and I'm afraid I just don't see what the risk is. Rollback just reverts edits. I don't see how it could possibly be used to originate vandalism. And even if it could the vandal would have to become autoconfirmed first, which grants them access to the better version of it that comes with twinkle. Very, very few vandals have the patience to wait four days and make ten good edits just so they can get a low-level tool that reverts slightly faster than just pressing the undo button. Beeblebrox (talk) 02:06, 2 February 2015 (UTC)
  4. Oppose getting rollback rights really isn't a hurdle, and enabling it for all is going to encourage more reversion without edit summaries. — xaosflux 03:41, 2 February 2015 (UTC)
  5. Oppose. This is a right that should be exercised by experienced users. -- Ssilvers (talk) 05:07, 2 February 2015 (UTC)
  6. Oppose: Upon being granted the privilege, caution is given to only use it in the fight against vandalism—never against good-faith edits. Allowing all users to rollback will cause a massive increase in misuse of the tool, including edit warring. With great power comes great responsibility, and that needs to be explained to new grantees. Otherwise, they risk having their "great power" revoked. – voidxor  05:29, 2 February 2015 (UTC)
  7. Oppose. I am not in favor of blindly granting this permission to potential vandals. This could be a great way for vandals to rapidly undo constructive edits. Also, inexperienced editors using such a gadget could roll back good-faith edits, deterring new users. I also agree with Cenarium's comments above that rollback is more reliable using the native mediawiki tool rather than a gadget, which can break. - tucoxn\ 05:56, 2 February 2015 (UTC)
  8. Strong Oppose - Many of the comments above address my concerns, but here is my take. Twinkle is a good start for new users who want to become involved in RCPing. Most importantly, it encourages them to leave an edit summary in cases that are not clear-cut vandalism and warn users, which is extremely important to both the user who is being reverted and a third party who might want a little information about the revert. Additionally, rollback and undo are not fundamentally the same. Rollback, in its current state, does not provide the option to leave an edit summary; therefore rollback ≠ the default undo, which allows the user to leave an edit summary, nor should them being interchangeable for new users even be implied. The potential for Rollback to be misused in an edit war and other scenarios is massive, hence why it is a user right which can both be easily granted and taken away. Opening it up to every Tom Dick and Harry is bad news in my eyes. Command and Conquer Expert! review me... 07:03, 2 February 2015 (UTC)
    I don't see how Undo can not be misused in an edit war in an equally massive way - it can actually revert more that Rollback can (given that Undo can revert edits by multiple users in one go) and it does not enforce an edit summary. Rollback actually appears to be more restrictive in what it can revert. Squinge (talk) 15:01, 2 February 2015 (UTC)
    Yes, but undo doesn't happen with a single click that leaves no expectation (let alone opportunity) for an edit summary. Proper use of undo mandates an edit summary for all reverts except the cleanup of obvious vandalism. – voidxor  06:15, 4 February 2015 (UTC)
  9. Oppose as long as the consensus on WP:ROLLBACK remains that it should not be used outside of reverting vandalism, edits by banned users, malfunctioning bots and self-reverets. Unchecked proliferation of this right will only enable more flippant edit wars, and make them more confusing (due to no meaningful summaries). Right now you can at least revoke a right that's being abused this way, and Twinkle is not so widespread (and considered an anti-vandalism tool, making people, in my opinion, less likely to enable it just to edit-war). Additionally, it runs the risk of enabling vandal bots running at much higher speeds (Twinkle, for non-rollbackers, as far as I know, does a regular "open-edit-form-on-past-revision-and-save" in the background, which is why it's slower than the "true" rollback button). At the same time I maintain the opinion that it's no big deal and I grant rollback on request to pretty much anyone without "shady" history. Tl;dr, it works well as it is. —Миша13 07:13, 2 February 2015 (UTC)
  10. Oppose per all above. Hafspajen (talk) 08:03, 2 February 2015 (UTC)
  11. Oppose. We are balancing the minor benefits of ease and speed against the potential for dissent and ill-feeling which can have significant negative consequences. It takes an experienced and thoughtful user to appreciate the impact a rollback (or any form of reverting) can have. SilkTork 09:14, 2 February 2015 (UTC)
    How is that different from the experience and thoughtfulness needed to revert multiple edits using Undo, which actually appears to be more powerful and can be done by anyone? Squinge (talk) 14:52, 2 February 2015 (UTC)
    Undo has a check-in interval, which is very important for newbies feeling out WP. Undo is often abused (WP:EW, anyone?), but at least it gives a sense of moment. Rollbacking is dangerously frictionless. FourViolas (talk) 15:11, 2 February 2015 (UTC)
    You can Undo as many edits in one go as you like with Undo. Go try it for yourself on the sandbox - I just did, and nothing stopped me. I honestly see no functional difference between the two in actual use other than that Undo can revert *more* in one go that can Rollback, and I can't help feeling that many people here are not actually trying to compare them before opining on the functional differences they think exist. Squinge (talk) 15:17, 2 February 2015 (UTC)
  12. Oppose I recently received rollback rights after spending quite a bit of time on WP over four months, and I've found my WikiKnowledge and WikiQuette barely equal to the minefield of judgement calls opened, from WP:BITE to WP:Oversight. I think giving rollback to good-faith newbies, let alone vandals, would add a lot of stress, confusion, and misunderstanding to the wiki. Thoughtful edit summaries are important, especially for newbies explaining what they think they're doing or having their first revert explained to them, and I oppose making it easier to leave them out. FourViolas (talk) 15:11, 2 February 2015 (UTC)
    So you think giving newbies access to something that is less powerful than they already have (ie Undo) is dangerous? Squinge (talk) 15:19, 2 February 2015 (UTC)
    It's not about what those tools can do, after all you could just load an old page revision and save it (it's faster than undo), it's about providing context. Rollback is just one click to revert, without any explanation given to the rollbacker, no check whatsoever. On the other hand, undo gives plenty of warnings, same thing when you try to save an old page revision, and with TW you have different rollback links with each of them explaining their purpose (vandal, AGF, ...), so there are plenty of checks and safeguards against misuse. For rollback, there is none. Cenarium (talk) 20:01, 2 February 2015 (UTC)
  13. Oppose. The last thing we should be doing is to make it easier to revert other editors. It's bad enough that the notification system now sends users a bright orange notice every time someone reverts you, as though this were an urgent problem that you have to go and respond to right away. I've been thinking more and more lately about how it seems like so many editors are angry so much of the time. A lot of it comes down to the fact that Misplaced Pages already makes it so easy to revert what someone else has done, instead of engaging with them and discussing it. It takes some experience to distinguish between an edit that satisfies the criteria for rollback, and an edit that should only be reverted with an edit summary. This proposal will move us in the direction of eliminating the whole idea of bold-revert-discuss (BRD), and change it to bold-rollback-ignore. --Tryptofish (talk) 15:48, 2 February 2015 (UTC)
    I don't want to sound like I'm badgering, but I honestly don't see how Rollback makes it easier to revert - Undo can revert more than Rollback can in one single action, and there's no right needed for that. Squinge (talk) 15:54, 2 February 2015 (UTC)
    That's OK, and I don't feel badgered. Undo includes the opportunity to leave an edit summary, and to make a deliberate choice about whether or not to mark the revert as a minor edit. Rollback allows no edit summary, and always marks the edit as minor. Those things can make a difference to the editor being reverted. Not having to think about those things is easier than thinking about them. I want editors to think about those things more, not less. --Tryptofish (talk) 16:44, 2 February 2015 (UTC)
  14. Strong oppose There isn't actually any reason for this to pass. We don't need to dole out every single tool that is meant for administrators just because it is meant for administrators. If certain users pass in allowance to obtain rollback permissions, then great. But I have already seen someone (in a manner of speaking) fall asleep upon their rollback button and derp-revert edits that were legitimate edits. Considering the amount of vandalism that occurs on Misplaced Pages each day, we really shouldn't be assuming that everyone is competent enough to use this tool. I say that we leave such things to approved editors, bots and administrators. Tharthandorf Aquanashi (talk) 17:41, 2 February 2015 (UTC)
  15. Oppose There are guidelines a user must follow and prove that they can be trusted with such a right. Making it more accessible would make vandalism/reverting a lot easier. ☯ Jaguar ☯ 17:59, 2 February 2015 (UTC)
  16. Oppose Twinkle rollback is not the same as this. It is a specific anti-vandalism script, albeit, it can be abused. However, rollback provides access to tools that can be used to greater damage. In a way, rollback is a demonstration of trust. It provides users who are interested in fighting vandalism with more options. Also, thinking about it, if rollback became a .js script gadget, it would then be easy for a user to take the .js for rollback, adapt it, and then use it to undo all edits as soon as they happen. Granted, worst case senario, but still, Lynctekrua (talk · contribs) gained access to sysop blocking scripts (see my comment). Someone with bad intentions could do worse with rollback, since it would not be restricted. Ignore the 'worst case scenario' if you think it is ridiculous. I have a wild imagination. Also, I agree with Cenarium in that the rollbacker user group is handy in an emergency where an admin could take some time to get to. And, there is also the general argument that edit wars would become much worse with access to rollback. Branching off, rollback is easier to use than Twinkle, as one only has to click rollback to undo an edit, but with Twinkle, you have an edit summary, as well as a warning selection. Good natured new users may make dealing with vandalism and counting warnings more difficult, as they could miss the addition of the warning to the offending user. -- Orduin 19:04, 2 February 2015 (UTC)
    This suggestion from MusikAnimal has my full support. -- Orduin 20:21, 2 February 2015 (UTC)
  17. Oppose for three reasons. Firstly we need some way of knowing users have read WP:ROLLBACK and know when the tool should or should not be used before it's granted. Secondly, misuse of rollback (if done in good faith) can currently be addressed by removal of the tool. With this proposal, the only solution would be blocking, which is extreme. Thirdly, what about existing admins/rollbackers who have javascript disabled? Optimist on the run (talk) 19:17, 2 February 2015 (UTC)
  18. I believe the tool, which is indeed a dangerous tool, can be abused too easily. Drmies (talk) 20:27, 2 February 2015 (UTC)
  19. Oppose per MusikAnimal. It's a fast way useful for reverting vandals and should not be made a gadget. Faizan (talk) 20:32, 2 February 2015 (UTC)
  20. Oppose: While I might support this if there had been proposed a way to deal with access to Huggle and STiki, as it stands this proposal would allow anybody to do massive damage with only a little prior preparation. I agree that Twinkle does provide similar functionality, but it is slower. I also agree with Command and Conquer Expert! and FourViolas that having a gradient of access to Recent Changes Patrollers both benefits their competence and understanding and reduces damage to the project by over-eagerness. Hell, when I was starting out, if I'd had rollback I probably would have been firing it off left, right and centre and got blocked, because I would not have known about it being, in usual circumstances, an inappropriate way to undo edits. BethNaught (talk) 21:28, 2 February 2015 (UTC)
    Yeah, Twinkle is a great way to get started safely. -- Orduin 21:30, 2 February 2015 (UTC)
  21. Oppose Rollback requires the right for a reason; unlike Undo or even Twinkle, where the entire page content must be sent to the server, rollback is initiated by a single link and performed completely server side. That makes it impossible to make it into a gadget. But what's more, it makes it very powerfull. When done correctly, I can perform 2 rollbacks per second, which is not possible with anything else. That makes it too much of a risk to grant to everyone; a vandal has only to visit an editors contribs page and do some serious damage! -- ] {{talk}} 21:55, 2 February 2015 (UTC)
  22. Oppose There are big technical differences between rollback and undo—rollback is much less server overhead, and all successive edits are rolled back, even those which occur after you look at the page history (if a vandal does 10 junk edits to a page and you click rollback after edit #6, all ten are rolled back). An important issue is the edit summary: rollback is just an automated and bland message that raises no excitement and which does not shout "ooh look at the vandal!" (WP:DENY). The rollback is marked as minor. Importantly, we generally trust rollbackers because their use of the tool is subject to review, so rollbacks do not have to be checked by other editors. Johnuniq (talk) 23:01, 2 February 2015 (UTC)
  23. Oppose Rollback is a powerful tool, and needs to be protected as such. We cannot let people who've only been here a few days and made some minor edits have a tool which can cause massive disruption and vandalism. Joseph2302 (talk) 23:31, 2 February 2015 (UTC)
  24. Oppose While I do appreciate the thought of making editing more accessible, I think this carries risk for too much abuse to the encyclopedia. Spencer 02:49, 3 February 2015 (UTC)
  25. Oppose - Personally I think Rollback is a very powerful tool and can do alot more damage than Twinkle, I'm also not comfortable with the fact vandals could use it, IMHO anyone wanting to do some reverting should like everyone else use Twinkle first. –Davey2010 03:51, 3 February 2015 (UTC)
  26. Oppose per above. Thought I like the idea, rollback is a strong tool. Say for example giving a fully automatic rifle to a starter, compared to a pistol, we'll have no clue what type of damage that could make... (lame example, but yeah) ///EuroCarGT 04:38, 3 February 2015 (UTC)
  27. Oppose I like to see numerous vandalism reverts before rollback is granted. Autoconfirmed just isn't enough for me and I feel there is too much room for abuse. Eurodyne (talk) 06:10, 3 February 2015 (UTC)
  28. Strong oppose: Though it might seem to be an insignificant utility, WP:ROLLBACK is actually like a chainsaw that can do a lot of damage very quickly if improperly handled by unexperienced editors. At the same time, anyone can undo as many edits as desired without being granted with WP:ROLLBACK, but that requires a few clicks more and that's what perhaps keeps many vandals away from doing that; laziness is a miraculous part of the human nature. :) Also, granting WP:ROLLBACK to everyone would promote the idea of reverting wihout providing edit summaries, what would be a very bad thing. With all that in mind, it's much better to just leave it as-is. — Dsimic (talk | contribs) 10:17, 3 February 2015 (UTC)
  29. Oppose - Rollback is one of the core admin power and it is granted to them who are able to revert quickly. Twinkle, though provide the option for rollback, does ask summary, thus at least giving a less probable ground for abuse. It is a powerful tool and we should not let people here for few days use it.  - The Herald (here I am) 11:03, 3 February 2015 (UTC)
  30. Oppose - TW (as an example) is more flexible, but the speed is very different. The server-side action of rollback is much quicker. I'm not sure how you can turn that into a js gadget. Even if you could convert it, I would still oppose this proposal as it stand. -- KTC (talk) 12:10, 3 February 2015 (UTC)
  31. Oppose Why on earth would we want to do this when it allows vandals to revert loads of good faith edits all the time? And it allows them to use additional tools like Huggle so what is the point of that? MadGuy7023 (talk) 17:32, 3 February 2015 (UTC)
    Vandals can already revert loads of good faith edits with Undo, without even being autoconfirmed. Squinge (talk) 17:57, 3 February 2015 (UTC)
    They can do it a lot faster with Rollback. And Rollback doesn't allow people to explain why they reverted the edit, whereas they can explain with the Undo function. MadGuy7023 (talk) 18:40, 3 February 2015 (UTC)
  32. Strong oppose. This will allow bad-faith autoconfirmed editors to game the system and use rollback inappropriately, in addition to gaining access to Huggle, STiki, Igloo, and other anti-vandal interfaces. Not only that, the granting of rollback shows that an editor is trusted enough to revert edits en masse and will make few mistakes. Should we allow pending change reviewing to become a gadget, too? We already have something similar, Twinkle, for those who don't have rollback (though it's really slow and requires going to the contribs page or diff-page, and then requires a summary on top of that as well). However, speed-reverts should be reserved for trusted editors anyway, and rollback is a right given because an admin trusts the editor to not abuse it. My point being: Twinkle is not rollback. (And also, making rollback a gadget is kinda like giving a bomb, rather than say a plastic knife, to someone who wants to cut up their chicken. Both are too risky.) Epic Genius (talk) 19:26, 3 February 2015 (UTC)
  33. Strong Oppose From Misplaced Pages the encyclopaedia anyone can edit to Misplaced Pages the encyclopaedia anyone can vandalise with the click of a button. No thanks. Leaky Caldron 20:20, 3 February 2015 (UTC)
  34. Fix Twinkle The core argument from Beebs is that because Twinkle allows this, Misplaced Pages should. The truth is that arguments have been made for years to fix this in Twinkle and the authors have resisted it claiming that checking a user's rights would cause unnecessary strain on Misplaced Pages's servers. Beebs should be making the opposite argument - because Hungle and STiki do this already, Twinkle should easily be able to incorporate this functionality. The "undo" feature is not technically similar to Rollback at all. Rollback can undo all consecutive edits by a single user with one click in an instant. Nobody can do that with the undo button.--v/r - TP 21:24, 3 February 2015 (UTC)
    Undo can undo all consecutive edits in one operation (even by multiple users in one go), but it needs two more clicks (it depends where you start from) - diff followed by Undo. Also, I think the difference between Huggle and Twinkle isn't so much one of checking rights, it's that Huggle actually uses server-side Rollback while Twinkle doesn't use it. Squinge (talk) 21:38, 3 February 2015 (UTC)
  35. Strong Oppose Removing the user right of the rollback will needed to have the removal from ALL of the MediaWiki projects.JordanKyser22 T 22:17, 3 February 2015 (UTC)r
    The proposal isn't to completely remove the rollback right from the software, just to remove the rollback user group on this project. Mr.Z-man 02:32, 4 February 2015 (UTC)
  36. Strong Oppose Anyone can edit to Misplaced Pages & vandalise with the click of a button which can cause massive disruption and vandalism. Babita arora 06:49, 4 February 2015 (UTC)
  37. Oppose It is more powerful than "undo" and would be open to inexperienced and nefarious users to create havoc. Peacemaker67 (crack... thump) 11:41, 4 February 2015 (UTC)
  38. Oppose Per Jasper Deng and many others. Manxruler (talk) 13:27, 4 February 2015 (UTC)
  39. Oppose Don't remove Rollback, it is an easy way to undo vandalism and even mistakes. Arussom (talk) 14:09, 4 February 2015 (UTC)
    Nobody is suggesting removing it! The proposal is simply to no longer have it as an admin-granted privilege. Squinge (talk) 14:29, 4 February 2015 (UTC)
  40. Strong oppose. I appreciate the proposer's point. But most of the other tools we're talking about here require at least a little bit of experience and experimentation. And if someone with said experience and experimentation wants to get nasty, s/he is likely to be able to find a way to do it, almost regardless of what we try to do. I see this as more about whether or not to make a potentially damaging tool more obviously and readily available to a "drive-by" bad actor without a lot of experience. Because rollback is so easy to use, making it easy to get to is particularly dangerous. (By the way, per WP:BEANS, I'd like this discussion to be quick-archived once it's complete.) StevenJ81 (talk) 16:23, 4 February 2015 (UTC)
  41. Oppose So after giving it thorough thought, I've settled on complete opposition. The best thing I could think of to address the concerns of the supporters was to simply rename the user group, see more below at #Rename rollback user group. I've given up on that, though.Why things are fine the way they are now: (1) Rollback is not the same as Undo, nor was it ever intended to supplement it. (2) Twinkle and Undo are not capable of system rollback, that is a single request to the server to undo all consecutive edits by one editor. (3) Rollback is primarily intended for anti-vandalism (quick, leaves no edit summary, marks edit as minor, available on watchlist), which is not the case for Twinkle and Undo (requires multiple clicks, offers to supply edit summary, not available on watchlist where edit warriors could more easily take advantage of it). (4) If Twinkle doesn't work with your browser, use Undo instead. If you are planning to be involved in counter-vandalism than apply for rollback, otherwise you have no need for rollback as that's what it is for. (5) Since rollback is for vandalism, it makes sense that anti-vandal tools use that as a restriction for access. (6) Because of all of the aforementioned, it makes sense why admins should be somewhat careful who they grant the right to. (7) Most admin tools are for anti-abuse, so it makes sense that rollback is one of them, but if desired rollback links can easily be removed with one line of CSS.Making rollback a gadget will be troublesome because: (8) We'd have to implement JS/CSS hacks. (9) Procedures at WP:PERM/R will need to be modified. (10) We'd have to find a way to enable the gadget for those who already have rollback now, the rest would need to opt-in. (11) Developers of anti-vandal tools will have to update their software. (12) We risk people misusing the rollback tool, however slim that may be. (13) Nothing is broken right now, so there's no need to alter the current system. — MusikAnimal 17:29, 4 February 2015 (UTC)
  42. Oppose, per reasoning given by others. While the move to disperse this to all autoconfirmed editors is understandable, the possibility for this tool to be abused is greater. There is a reason why this tool needs to be requested. It might not be super difficult, but it's a check to ensure that the tool isn't placed in the wrong hands.--RightCowLeftCoast (talk) 20:32, 4 February 2015 (UTC)
  43. Oppose Really, the last thing we need is to turn a server-side useful tool into yet more clunky javascript. We use too darned much of it already. If you want to do this, add the right to the "autoconfirmed" user group, and let people hide it by CSS, rather than breaking a good, low client-side resource tool. Courcelles 22:15, 4 February 2015 (UTC)
  44. Per Courcelles; half of my scripts don't even load now since there's so many. We should be moving stuff into the interface from JavaScript, not the other way around. --Rschen7754 04:25, 5 February 2015 (UTC)
  45. Per MusikAnimal, Courcelles, and others. INeverCry 05:22, 5 February 2015 (UTC)
  46. Oppose; currently twinkle somehow includes Rollback and it is a gadget too, but as it can be seen there are many users who are not rollbackers or they have been omitting from this group due to abusing of this access. Rollback should only be used for reverting vandalized edits, while there is a high potential of edit war if it is misused. Concisely this should be kept as a an access for a group of users whom we know they would not use this access except in reverting the vandalized edits. ●Mehran ● 07:47, 5 February 2015 (UTC)

Discussion

  • Considering the speed at which rollback acts, I'm not sure I like the idea of this right ending up in the hands of vandals. Twinkle rollback has a greater delay (at least, based on my own experience). Aside from that, it isn't that difficult for legitimate users to obtain access to the right, is it? Dustin (talk) 21:48, 1 February 2015 (UTC)
Depends who you ask. Requests are submitted at WP:PERM and are usually handled fairly quickly, but standards seem to vary from one admin to the next. And that is what I believe to be the central issue here: this is a pretty weak tool, weaker than other tools users can have without having to ask anyone. So why restrict it at all? The vast majority of actual vandal accounts never get to the point of being autoconfirmed and for the tiny minority that do blocking is surely a more effective defense than revoking just rollback. Beeblebrox (talk) 22:22, 1 February 2015 (UTC)
  • Twinkle delay to perform this task is next to no time; the "restore this version" option is clicked, then a few seconds later, Twinkle restores the old version of the page ... probably technically by the same means that any editor can which I have outlined in my "support" vote above. Steel1943 (talk) 22:32, 1 February 2015 (UTC)
  • I've not seen any noticeable difference in speed of operation between Rollback and the Twinkle version. Rollback might be a lot quicker at machine level, but once the UI, the internet, and all the latencies between machine and user are taken into account, machine-level speed surely becomes irrelevant in considering using the thing as a tool. Squinge (talk) 09:48, 2 February 2015 (UTC)
  • On my side rollback is almost instantaneous, taking no more than half a second, while twinkle takes three or four seconds, with multiple intermediary windows and page updates. I never use twinkle as I find the native rollback much more efficient. Cenarium (talk) 07:08, 3 February 2015 (UTC)
  • As one of the regulars at WP:PERM/R, I get what Beeblebrox is saying. Myself and others are a bit strict about granting the right, and for me much of this is because it provides access to powerful semi-automated tools like Huggle. I'd like to think so long as we are still able to grant access to those tools on a case by case basis, there's no issue with the proposal. The problem is you can go so quick with semi-automated tools monitoring recent changes. Inexperienced users may end up rolling back good-faith edits, deterring new users, and vandals in the know could wait till they're autoconfirmed and then go on a rampage. The more I think about it, I worry the same issues could occur without any semi-automated tools. Just right-click the rollback links to open in a new window, for each entry at Special:RecentChanges, and you could cause a lot of damage very quick. As far as I know this is not possible to do that easily with Twinkle, and certainly not undo. The other issue is a lot of honest new users have no idea about additional features like undoing and other means to restore older revisions, and when they're 10+ edits are rollbacked with one edit they are naturally upset given all the work they put into it. That being said, you're average vandal or edit warrior may also not know they can simply enable the rollback gadget, just like many editors have no idea about Twinkle. It's all theoritical, and I could go either way. I guess the bigger point I want to make is that if admins being too strict about granting the rollback permission is the issue, we can focus on that instead of reworking how permissions work site-wide, that will be inconsistent with other wikis and conflict with tools built around rollback. I'd have to argue that as it stands now, there's more risk in granting rollback than there is in refusing to grant it, regardless that Twinkle is there for anyone. If the rollback candidate isn't active in anti-vandalism than they won't be a frequent user of rollback anyway. But here again, I understand the redundancy with Twinkle... — MusikAnimal 23:45, 1 February 2015 (UTC)
  • @MusikAnimal: Just an FYI: above, I stated the way which any editor can perform a "rollback" without even needing access to the rollback user right. My assumption is that the way I outlined is how Twinkle accomplishes the task without its operator needing the rollback right. Steel1943 (talk) 23:55, 1 February 2015 (UTC)
  • I'd like some clarifications. If rollback is changed to a gadget, is this going to use some javascript hack ? Because traditional rollback does not, and it should stay that way. Cenarium (talk) 01:31, 2 February 2015 (UTC)
I would hope the implementation would be to add rollback to the auto-confirmed user group, and just have rollback links not display until an editor ops in. We could just disable the rollback links for everyone with CSS (as some of us already do ".page-Special_Watchlist .mw-rollback-link {display:none}") and then when they opt in, unhide it. Monty845 03:35, 2 February 2015 (UTC)
This would still require js to unhide it, and in case of javascript failure on the site, they would then again be hidden, so it doesn't solve the problem of gadget failure. Unless we hide the links using js (and not css), so in case of javascript failure on the site, the rollback links are shown to all autoconfirmed users ... or not, the behavior would be widely erratic. Is this something we want ? Cenarium (talk) 04:04, 2 February 2015 (UTC)
Actually this could work as an opt out. We make a css gadget that hides rollback links and is enabled by default. In order to activate rollback, users would have to disable the gadget. A failure of css is much less likely than a failure of js, and in this event, all autoconfirmed users would be shown rollback links, which isn't as bad as no more rollbacks for everyone. Cenarium (talk) 04:19, 2 February 2015 (UTC)
  • My only concern is the nonchalance associated with what will become of Huggle access. I believe that important consideration should be addressed as part of this RFC. And I believe if it is not properly answered here, we are likely to end up creating more problems than what this proposal is poised to resolve.--John Cline (talk) 01:49, 2 February 2015 (UTC)
My take on that is basically that Huggle should have its own criteria and not rely on admins at PERM, who may not be familiar with huggle, to screen users for them. AWB has it's own requests page, there's no reason huggle couldn't have that instead of forcing everyone who just wants rollback to go through the process just for the sake of huggle's maintainers.
I also think if this concern is to be taken seriously that persons familiar with huggle should make more of an effort to be explicit in explaining exactly how it could be misused to commit acts of vandalism as it is not really clear to those of us who don't use it. Beeblebrox (talk) 02:01, 2 February 2015 (UTC)
It can be used for malicious acts on a large scale, e.g. reverting good edits intentionally, which can be considered sneaky vandalism, as much as blanking content with malicious intent is vandalism. I guess if we add HG and ST users, and admins, we get enough users to handle vandalism in the event of a gadget failure. So what if non-admin rollback was restricted to active users of Huggle or STiki (or in the future any other similar tool for which it makes sense) ? Users desiring access to those tools would have to first gain approval for access to the tool, and an admin would grant rollback only then. Admins would then only have to check if they have gained access, no need for vetting beyond that, and no need to advertize a central request page outside HG / ST documentation pages. Cenarium (talk) 03:07, 2 February 2015 (UTC)
@Beeblebrox: As I understand it, in the worst-case scenario, if Huggle fell into the wrong hands, they could disable any filtering, hold down the Q key and rollback every single change site-wide in real time. That is assuming you can actually hold down the Q key (revert as vandalism key) which of course I've never tried. Even if you can't hold down that key, you could still very quickly click the revert vand button, over and over... If it is not peak hours, it could take several minutes for an admin to block, meaning we could have hundreds of (potentially) constructive edits undone. Without administrative tools I can't think of a way to cause more widespread damage than this. This is why I am strict at WP:PERM/R, as even with well-intended vandal fighters, they simply go too fast with the software and make too many mistakes. Restricting this access I believe is paramount to this proposal. — MusikAnimal 04:29, 2 February 2015 (UTC)
@Beeblebrox; I agree with the preponderance of rational you have given, and I am hopeful that this proposal is as sound as it primarily appears to be. Mine is just a concern I want to mitigate before !voting, and I have to admit that Cenarium's well articulated concern challenges my understanding enough that I now have two questions I want to see answered before I !vote. Regarding the editing aids that are rollback requisite, I want to know that the transition will be smooth and for the most part, uninterrupted. I'd like to know that a grandfather clause is incorporated and that the core users who have used a particular interface will be seamlessly added to whatever control group they may need to be in. And of course, I would need to be sure that no kinda of slip could possibly occur that would allow a 10 edit 4 day warrior to access the likes of Huggle when they are that overqualified. Affirmative answers to those questions will allay the concerns that I originally had, Cenarium's answer will stand on its own merit, and if it is strong enough, as I said: I will gladly support this proposal.--John Cline (talk) 03:20, 2 February 2015 (UTC)
My oppose has nothing to do with huggle, it is not official and the huggle devs can always make up whatever rules they want. — xaosflux 03:43, 2 February 2015 (UTC)
  • In addition to the well founded concern about Huggle access, there are some extremely powerful scripts based on rollback that are floating around in odd corners of userspace, including one that allows rolling back 500 of a user's contributions at once. While hypothetically someone could code them to not require rollback, the ones our there do, and could cause significant disruption if abused. That said, when used manually by editors, abusing rollback is at most minimally more disruptive than existing editing options open to everyone. Monty845 03:45, 2 February 2015 (UTC)
  • I was thinking of a similar scenario to Monty: Even if Huggle and STiki restrict usage in another way, there are a few mass rollback scripts (such as User:John254/mass rollback.js) currently available and it's not hard to write one so a vandal, or one of those sock masters, could get autoconfirmed, install or write a mass rollback script then go to a couple of usual vandal fighters (or any users') contribs and mass revert causing havoc (both the reverted edits being live and there being hundreds of rollbacks happening at the same time).
If autoconfirmed rollback had a fairly tight rate limit on it (which could be relaxed once the user has more experience, not sure if that's possible without another userright?) I could see myself supporting, but until then I'm not convinced that the benefits will outweigh the potential problems. Another way I'd support is if we made rollback automatic after a specific period of time and edit count (that is, takes longer than autoconfirmed, perhaps reflecting the current standards used at WP:PERM). Callanecc (talk • contribs • logs) 13:44, 2 February 2015 (UTC)
You don't need rollback to do mass reversion with a script. Possibly you could do twice as much damage in the same time frame, or something, I don't know the technical details. W. P. Uzer (talk) 14:16, 2 February 2015 (UTC)
Indeed. if Undo is available to script writers, it can do exactly the same thing as Rollback. The only real functional difference, as I see it, is that Rollback does not allow for an edit summary. Squinge (talk) 14:23, 2 February 2015 (UTC)
Actually, scripts can add edit summaries to rollbacks, they just need to append &summary= followed by the edit summary to the rollback. (Can be done manually, but not a very efficient way to do things) Monty845 14:31, 2 February 2015 (UTC)
Ah, so there's apparently no functional difference, script-wise, between Undo and Rollback then. Squinge (talk) 14:33, 2 February 2015 (UTC)
This is above my level of technical expertise, but my understanding from past discussions is that rollback is faster because only one command is sent to the server, whereas undo requires multiple steps, and undoing multiple consecutive edits requires even more intermediary steps before the change is applied. While a script can handle all those steps without additional user interaction, it is slower, which is a bad thing if you have a legitimate reason to mass revert, or a good thing if its slowing down a vandal trying to do the same thing. Monty845 14:40, 2 February 2015 (UTC)
That sounds like Rollback should be preferred over Undo, as it is easier on the server. And Undo is not slower for vandals, because you can actually revert far more in one action with Undo than you can with revert - Undo is *faster* for vandals! Squinge (talk) 15:05, 2 February 2015 (UTC)
  • Comment. There seems to be a lot of argument here based on ignorance of how Undo works. I've tried it in the Sandbox, and you can undo multiple edits by multiple users in one go - it can do more than Rollback! Squinge (talk) 15:07, 2 February 2015 (UTC)
    • But rollback can as well, can't it? In any case, though, by simply going to the edit history and opening and saving one of the past versions, you can revert any desired number of edits by any number of editors. For a script (an unauthorized bot), none of this takes any time at all. And no-one will make you leave an edit summary if you don't intend to do so. W. P. Uzer (talk) 16:05, 2 February 2015 (UTC)
      • Yes, that is my point - why should we restrict Rollback when the unrestricted Undo can do everything it does and more, with just as much ease? I can't help feeling that a lot of people here think that Undo can only revert one edit at a time! Squinge (talk) 16:15, 2 February 2015 (UTC)
  • Comment: There seem to be three basic types of reversion we're talking about here — (1) Revert all edits by user X with automated summary (2) Revert all edits by user X with automated summary + optional comment (3) Revert edit(s) partially or edits by multiple users with optional summary. The rollback tool seems to fall under #1, but all three of these options are available without it. I use Twinkle for the first two and the Undo function for the latter. I don't have the admin tool, but can't see anyone here pointing to a unique feature it provides. So I don't see why it would need to become a gadget — can it not just be removed altogether? — Bilorv(talk) 17:51, 2 February 2015 (UTC)
  • I'm seeing a definite pattern emerge in the comments here. Users with older accounts, who may even recall when only administrators had this tool, fear that it will grant untold power to vandals. Users who have been around for just the last few years, on the other hand, largely find rollback weak to the point of being almost useless because there are so many other tools that actually do a better job and do not require asking an admin to use them. No offense to those who are opposing as I'm sure they are doing so in good faith, but I think many of you are living in the past and haven't come to grips with the fact that rollback's time as tool of awesome power is long over. The reason most people ask for it now is so they can go ask for permisssion to use other tools. If they already use twinkle they don't need it at all, and in fact it just gets in the way. Beeblebrox (talk) 19:50, 2 February 2015 (UTC)
    @Beeblebrox: That's it in a nutshell. Rollback is for the fastest way to undo consecutive changes, but moreover access to the more powerful tools. An alternative to this proposal is to simply rename the user right to something like "vandal fighter" (no offense to those who initiated that proposal, I just think it's a fitting name). That is, vandal-fighter gives you a quicker way to undo consecutive changes, it's available on your watchlist, and grants access to all the anti-vandal software. Twinkle and undo can't do any of those (keyword FAST). More at Help:Reverting. Basically if we just renamed the user right we'd rid the concern about redundancy, avoid these CSS/JS hacks, none of our procedures at PERM would need to be modified, those who already have rollback would be unaffected, developers don't have to update anti-vandal software – essentially still allow things to operate in the same way that they do now. How does that sound? — MusikAnimal 20:14, 2 February 2015 (UTC)
    To clarify, rollback was never intended to supplement undo. Rolling back with Twinkle is a two-step process unless you have rollback. Undo is always a two-step process. Neither Twinkle or Undo are available on your watchlist – which is where the edit warriors would take advantage of it. — MusikAnimal 20:22, 2 February 2015 (UTC)
    @MusikAnimal:An alternative to this proposal is to simply rename the user right to something like "vandal fighter..." – If such a change were initiated I'd be more in favour of calling it something like "Trusted user" or "Trusted tool user" and not having it inherently have anything to do with fighting vandalism. It would be a check that an admin has reviewed the user and found that they know what they are doing. That way any current or future tool powerful enough to require restriction to access, regardless of if it has anything to do with vandalism fighting, can use the user right to check if a user should be able to use it. This prevents the possible situation where a tool used for other types of editing ends up using the "Vandalism fighter" right as a check simply because it is the closest thing we have that is appropriate, much as the rollback right is currently being used for now (even though the current tools aren't necessarily being used to perform rollback, but rather widespread changes) (sorry I was thinking AWB could be accessed with rollback rights, but it would still avoid the need for separate lists for each tool).  DiscantX 23:12, 2 February 2015 (UTC)
    • I'm an opposer, but don't see it as a vandal threat. I doubt many vandals would go to the effort of creating an account, waiting till it's auto-confirmed and finding the relevant gadget. However I do find rollback more powerful than undo, if only because it eliminates the "save" click, and therefore removes the "are you sure" element. I don't use Twinkle, so maybe others find that even more powerful. That being the case, and if newer editors don't find rollback to be that powerful I don't really see the point of this proposal. Optimist on the run (talk) 20:04, 2 February 2015 (UTC)
      • @Beeblebrox: I'm afraid "Smell ya later, gramps!" is not a legitimate means of discussion. It's both rude and naïve. He that wishes to change something purely for the sake of sticking it to the man is just as foolish as he that wishes to retain something purely to maintain the status quo. Heckling those that disagree with this proposal on the subject of the age of their accounts, purely because you cannot actually find a legitimate point of argument against their reasons of opposition is argumentum ad hominem, which is not a legitimate manner of argument.
Feel free to try again with a legitimate rebuttal, though.
My apologies if you did not mean your comment in a rude manner, but you must understand that argumentum ad hominem is the oldest false argument in the book. I, for one, am sick of seeing it used so much these days as if it were actually a legitimate manner of rebuttal. Tharthandorf Aquanashi (talk) 20:28, 2 February 2015 (UTC)

Al I can say to that is that I think anyone can see that you have grossly mischaracterized my remarks, decried mu supposed use of ad hominem arguments while making one yourself, and put words in my mouth that I never said or intended. Beeblebrox (talk) 20:42, 2 February 2015 (UTC)

@Beeblebrox: Where did I make an ad hominem argument against you? How did I misrepresent what you were saying? I merely pointed out that randomly drawing attention to a general account age difference between some of the opposers and supporters, as well as statements like "I think many of you are living in the past" are not rebuttals. They are purely statements against the individuals that are opposing, rather than statements against their arguments. So, indeed, argumentum ad hominem. Clear as crystal.
I'm sorry if I'm coming off harshly, but it is quite sly of you to try and make an ad-hominem argument appear as if it were an actual argument. I simply am not going to let that be ignored, because too many people try to do that today and actually succeed in doing so simply because no one ever speaks out against it.
So, again, do you have any actual rebuttals against any of our points?Tharthandorf Aquanashi (talk) 20:47, 2 February 2015 (UTC)
  • I'm new as a registered user, but have edited a few things in Misplaced Pages before. This is the first time I read about "rollback," but from what I've read so far, it seems to be a good thing to have. Both the gadgets and the current "rollback" features are harder to find unless a user sees it advertised as it has just now (with this request for comment). For years I'd used Misplaced Pages (granted: every now and then), and only now, having registered, did I learn about this issue. However: I noticed recently that it is possible to hit "undo" in the history of edits, and thought it was a bit risky to have that feature (too accessible, even by non-registered users). I even noticed a page where the same phrase (a stupid phrase and not at all related to the article) had been added and deleted over and over, perhaps through use of the "undo" function. It becomes bothersome for people who are seriously trying to improve an article to have to look through so many of those changes which can be done so easily. So I would agree (based on the observations just mentioned) that vandalism would be easier with a feature mentioned to newly-registered users in their preferences page. From my understanding of "rollback," it seems that it gives one more hurdle to vandals and/or "newbies" before they can make significant changes to pages. I also agree with user "MusikAnimal" (who commented above) in that the main issue should be more about the way in which the right is granted, than about abolishing the process for granting it altogether. And it occurs to me that the idea should go even further than that, and consideration should be given to having a process to grant rights to "undo" big sections of edits in an article, or at least find a way to prevent multiple mindless "undo"s of edits (as the one I described above). The gadget thing also seems to have sneaked up on the whole rollback system, and I'd say that it, too, might be worthy of revision. Capikiw (talk) 20:54, 2 February 2015 (UTC)
  • As someone very new to Misplaced Pages, I would worry about accidentally hitting rollback instead when trying to do something else. I understand that for more experienced editors this can be a crucial tool. Is this proposal suggesting automatically putting a rollback button or something like it on everybody's screen, or that editors could choose to have that button there or not (with default being not)? Because if it just appears, I don't trust myself not to get confused. If you have to find it in a list and enable it, then I have no problems personnally with it. Happysquirrel (talk) 02:44, 3 February 2015 (UTC)
    @Happysquirrel: As I understand it, the current proposal is to make this an option which can be turned on and off in the "Gadgets" area of your preferences. I think the default would probably be off. — Bilorv(talk) 08:13, 3 February 2015 (UTC)
  • Suppose that rollback were given to all autoconfirmed users. That would allow them to access tools like Huggle, which are dangerous because of their power to rapidly revert contribs, much faster than one could with undo. Vandals having their hands on this, even for a few minutes before a block, could have a devastating effect - but consider also a well-meaning but over-keen new vandalism patroller who may not know the ins and outs. For those who have never used it, Huggle is a real power trip when you first use it. With great power comes great responsibility, and autoconfirmed is insufficient responsibility. BethNaught (talk) 18:48, 3 February 2015 (UTC)
This is exactly why I believe the huggle argument is a red herring. As far as I am aware this was just a decision the developers of the tool made, altering the purpose of requests for rollback without getting a community cionsensus to do so, in order to make screening for their tool easier. When I see a request for rollback based on wanting huggle access, I don't evaluate it any differently than any other request because rollback in and of itself is not a "great power" at all and the community has agreed in the past that the bar for attaining it is pretty low. So all I am suggesting here is that we make that bar even lower because it is such a weak tool. Huggle can do like AWB and have people who are actually familiar with the tool review requests to acfeess it instead of shoehorning it into another process. Beeblebrox (talk) 19:07, 3 February 2015 (UTC)
(edit conflict)Actually, looking at the documentation for Huggle, the capability to do this already exists. So it would require no changes by the developers, just some simple changes to the configuration page here. Mr.Z-man 19:11, 3 February 2015 (UTC)
OK, so I wasn't aware Huggle was that configurable in terms of accessibility. Nevertheless, were this proposal agreed to, we would first have to get the developers of Huggle, STiki and Igloo to modify their scripts and somehow force Hugglers etc. to take a software update incorporating the new access controls? BethNaught (talk) 19:18, 3 February 2015 (UTC)
That would create unnecessary work for them, and the situation would turn by "access by request or with rollback" to "access by request", which I'm sure would make a huge amount of work that these developers wouldn't want. Epic Genius (talk) 19:36, 3 February 2015 (UTC)
I would argue that it would put work on them that should have been doing for themselves in the first place. Please do correct me if I'm wrong, but did the huggle devs even ask admins or the community if they wanted WP:PERM to be used as a pre-screening mechansim for their tool? If AWB can manage it I don't see why huggle can't. Beeblebrox (talk) 20:39, 3 February 2015 (UTC)
With Huggle at least, the access controls are set on a config page here that the software should load every time it runs, so any recent version should work fine. And there already is a configuration option to force people to update when necessary. I haven't checked STiki and Igloo, but if they're designed with any sort of common sense, people should not be able to bypass access controls by using an old version of the software. Mr.Z-man 20:45, 3 February 2015 (UTC)
STiki devs have the capability to disable older versions of the software and force people to update, so that looks like one less issue. APerson (talk!) 22:30, 3 February 2015 (UTC)
As STiki developer, I'll note I have been skimming these discussions. Note that STiki currently allows users with (a) the rollback permission, or (2) at least 1000 article space edits to contribute using the tool automatically. Myself and other STiki supporters sometimes field requests for approval from users who do not meet these criteria, and I am guessing we approve about 50% of those (pointing the rest to WP:CVUA). I have always preferred there to be some barrier-to-entry for users, as poorly behaving users don't just get themselves in trouble, but (fairly or unfairly) some of that criticism also comes back at the tool. West.andrew.g (talk) 20:46, 4 February 2015 (UTC)
  • People keep missing the point of site security with this flurry of proposals which are going nowhere. Native mediawiki rollback must remain available at all times for all admins in case of emergency, such as a server failure (of the kind that occured two months ago), or a rogue admin messing around in mediawiki namespace. In both cases, gadgets would become unavailable, and in the later case it may not even be possible to use undo. Rollback is an essential admin tool, like block, and ought not to be removed from the admin toolset. Cenarium (talk) 03:31, 4 February 2015 (UTC)
  • If only there were a "neutral" section. I'm not fully swayed towards either side. Kurtis 12:28, 4 February 2015 (UTC)
@Cenarium: Blame the stark liberalism of modern society, contrasted with the stark "conservativism" (allegedly, though it's more like "keep it the same because I don't want to change it-ism") that mirrors it. If only we could have more true, independent-minded individuals in this world. Wellawoe, though, more people are sheep than are self-leaders. Tharthandorf Aquanashi (talk) 13:23, 4 February 2015 (UTC)

Suggestions

Run a test elsewhere first

Since Beeblebrox does not seem to wish to respond to my question, I will simply propose this (my vote remains the same as of now, however): What if this were to be tested somewhere else on the Wikimedia projects first, where it might cause less trouble, as a test first. If the test proves successful, perhaps people currently in opposition will change their minds. If the test proves unsuccessful, then perhaps the people currently in support will change their minds. Tharthandorf Aquanashi (talk) 04:42, 3 February 2015 (UTC)

Other projects/wikis are not there just to support en.wp. They are independent part of the family in their own right. If en.wp want to test something, then en.wp can test it. -- KTC (talk) 12:06, 3 February 2015 (UTC)
Whilst that is true, it does not mean that they couldn't be asked for help in this matter. They could refuse, of course, but they might accept. For instance, what about the Simple English Misplaced Pages? Tharthandorf Aquanashi (talk) 12:50, 3 February 2015 (UTC)
I doubt that tests on tiny Wikipedias would do anything to assuage fears of the kind of damage that opposers believe could happen here on the biggest of them all. Squinge (talk) 14:00, 3 February 2015 (UTC)
How many people vandalize, say, the Simple English Misplaced Pages (as a ratio to English WP)? And how many would use rollbacking beneficially? Also, how long would the test last? I think it's probably too small a sample and would take too long (especially to get approval on whichever project). — Bilorv(talk) 15:58, 3 February 2015 (UTC)
I've heard some people say that some vandals go to the Simple English Misplaced Pages after they have been banned, particularly some notorious ones. Furthermore, I've heard that the Simple English Misplaced Pages is laxer in some ways on some things than the English Misplaced Pages. I really think that it would be a good test, and would shed some light on how instituting this here might work out.
Furthermore, @Bilorv:, "ow many people that don't already have access would use rollbacking beneficially?" is one of the things that such a test would work out. Tharthandorf Aquanashi (talk) 17:57, 3 February 2015 (UTC)
How would we work this out? Would there be some way to work out the number of edits made with rollback by people without access previously, or would we rely on some kind of feedback form? I suppose "notorious " is probably the group we're most concerned about when it comes to abuse of the feature; the common vandal might add "poo" to a couple of articles but certainly won't master the undo tool. So maybe it might yield useful data if we tested the gadget idea on a slightly smaller WM project. — Bilorv(talk) 20:26, 3 February 2015 (UTC)

Remove rollback?

This is going to sound ludicrous, but what if we removed rollback, as Twinkle pretty much does the job, and made Huggle a right? Thoughts? Or maybe keep rollback, as gadget, and make Huggle a right, as this seems to be a common worry. Eman235/talk 19:56, 3 February 2015 (UTC)

Hmm... that's an interesting proposal. Would you care to elaborate upon it a tad further? Tharthandorf Aquanashi (talk) 20:02, 3 February 2015 (UTC)
We could either just get rid of rollback altogether -- do we really need it? -- or keep it as a gadget, but either way I would suggest making Huggle something like AWB, i.e. requiring admin permission. Eman235/talk 20:06, 3 February 2015 (UTC)
If we were to remove it, and then make Huggle require administrator permission to use, that may well be a possible solution, mayhap. Tharthandorf Aquanashi (talk) 20:09, 3 February 2015 (UTC)
Well, I really need WP:ROLLBACK, for what it's worth. To me, using more complicated utilities doesn't make much sense, when a simple but efficient one does the job, and does it well. — Dsimic (talk | contribs) 20:14, 3 February 2015 (UTC)
  • While i can certainly see the temptation to do it this way I don't think it's a good idea. This proposal was intended to make things more fair, so that some users would not have to ask for something that others can have for the taking. Unfortunately twinkle actually does not work at all on some browsers. This would force them to jump through hoops for huggle access when they may only want simple rollback and this is the only way they can get it. It would just turn the existing problem on its head instead of solving it. Which is really too bad, this would otherwise have been a good solution. Beeblebrox (talk) 20:23, 3 February 2015 (UTC)
    @Beeblebrox: What makes you think that people shouldn't have to jump through hoops to achieve something that they should need to be trusted to use? I'm really confused by your way of thinking on this. Do you also propose that all users should be able to have oversight abilities? Seriously, you didn't respond to my other ping before for some reason, but I'm seriously asking you: why do you feel that people shouldn't have to work hard to obtain something that can be otherwise problematic if just haphazardly handed out? Tharthandorf Aquanashi (talk) 01:33, 4 February 2015 (UTC)
    How about we retitle this section "make Huggle a right"? I had forgot about Twinkle not working in some browsers. Eman235/talk 20:26, 3 February 2015 (UTC)
    Just create another section, that should be less confusing. — Dsimic (talk | contribs) 20:28, 3 February 2015 (UTC)
That's a ridiculous comaprison. Oversight is one the most powerful tools we have. Rollback is the weakest. A user who abused oversight permisssions could cause incredible amounts of real-world damge by revealing libel or private information. The last person I can recall who abused that ability had all their advanced permissions revoked by the office, that's how serious it is. On the other hand, a user who abused rollback could revert some edits, which they could also do without rollback.
I don't know why it is so hard for you to understand that the point here is that more powerful tools are available to use without permission from anyone, so it is unfair to restrict access to this tool for those users who cannot or would prefer not to use twinkle. Why should some users have to work hard to get access to abilities that users who happen to use a different web browser get by default the instant they are autoconfirmed? That's what doesn't make sense. Beeblebrox (talk) 01:52, 4 February 2015 (UTC)
Since plans already exist for Twinkle to undergo a merger with FurMe, whilst this merger is taking place, perhaps further work on Twinkle to allow better access in other browsers could be done, or (if that is impossible) some alternative for those browsers to be made. Unless the browser you are referring to being incompatible with Twinkle is something like Internet Explorer. If it is, then I don't know what to tell you. Microsoft shouldn't be being so backward with their browser that it would be incompatible with JavaScript related tools. Tharthandorf Aquanashi (talk) 02:06, 4 February 2015 (UTC)
It is infact incompatible with IE, versions 8 or older. While I can't imagine why anyone would want to use those browsers to begin with, some people do still use them. But that still isn't the point, the point is that it simply doesn't make sense to restrict one version of a tool when antoher version of the same tool is free to all. Users should have the choice to use whichever version of rollback they prefer. This would make that happen. None of these pther proposals would do that. Beeblebrox (talk) 02:16, 4 February 2015 (UTC)
We could have a poll (or, more simply, ask here how many people do) done for how many people use Internet Explorer Version 8 or prior, if it came to that. Tharthandorf Aquanashi (talk) 02:19, 4 February 2015 (UTC)
  • Rollback is technically superior in cases where mass reverting is really needed. If I need to revert 50 or 100 edits from one editor for some legitimate reason, I can just hit rollback after rollback, without need to wait for the pages to load, or provide further input as you would with undo. Twinkle still does the extra page loads, even if it does the rest itself. Thus rollback is technically superior. We shouldn't throw the baby out with the bathwater, and remove a superior tool just so that everyone is more equal. Monty845 22:13, 3 February 2015 (UTC)
I'm not sure how that would help when I'm not using huggle to rollback. The key is that rollback is skips the need to load the content of each revert, and just has the server do it. I don't think huggle could do that either without access to rollback. Monty845 01:47, 4 February 2015 (UTC)
I never said that it couldn't access it, I'm just saying that they would be merged. Rollback could technically be retained if absolutely necessary, but only so that it could be accessed by Huggle. It would otherwise be greyed out or invisible; inaccessible to anything else but Huggle. Tharthandorf Aquanashi (talk) 02:14, 4 February 2015 (UTC)
As already noted, "using more complicated utilities doesn't make much sense, when a simple but efficient one does the job, and does it well." I'd just change "much sense" into "any sense". :) — Dsimic (talk | contribs) 02:52, 5 February 2015 (UTC)

Make Twinkle a right?

This may just be plain weird, but if rollback is made a user gadget, what if Twinkle becomes a user right instead of a gadget? Twinkle can use MediaWiki rollback, and the rollback gadget could be a slower type of rollback, requiring an edit summary. Epic Genius (talk) 20:38, 3 February 2015 (UTC)

I'm not at all sure why this would be a good idea. Beeblebrox (talk) 20:48, 3 February 2015 (UTC)
This seems to leave us with a similar situation to where we started.... -- Orduin 20:50, 3 February 2015 (UTC)
Hey, if we're going to remove rollback as a user right and turn it into a gadget, this should be the alternative. Just sayin'... Epic Genius (talk) 21:02, 3 February 2015 (UTC)
I see the logic here, just have to think about it! -- Orduin 21:07, 3 February 2015 (UTC)
Not possible. Twinkle is a client-side application. You can't really control who uses it or not. Rollback links are server-generated and work if and only if you have the necessary right. —Миша13 21:09, 3 February 2015 (UTC)
If I recall correctly that's why it was made into a gadget to begin with. There used to be a blacklist of users who were not supposed to use it, and it was discovered that some of them were anyway somehow, so it was moot. I don't see a tit-for-tat reversal as serving anyone's best interest. Beeblebrox (talk) 23:05, 3 February 2015 (UTC)

What if we had a bot to process most rollback permission requests?

I'll admit it is usually a very manageable amount of requests, most are handled within a day or two. My contention is that no vetting should be needed at all and admins could be spending their time or more important tasks. Beeblebrox (talk) 23:07, 3 February 2015 (UTC)
I would, however be open to the idea that it be an automatically-granted user right like autoconfirmed, provided there was some way not to have it if you don't want it. It's an interesting idea as it seems to meet a middle ground between my proposal and the concerns of a lot of the opposers that vandals would get access to more powerful tools via rollback. Beeblebrox (talk) 23:12, 3 February 2015 (UTC)
That makes sense to some extent, but I really don't see why should everyone be automatically granted with the rollback functionality after, say, 500 edits? The rollback is mostly for the people who want to deal with vandalisms by reviewing recent edits, and (based on the articles I deal with) not too many editors seem to be interested in doing that. — Dsimic (talk | contribs) 23:19, 3 February 2015 (UTC)

How about "You may now activate rollback, it's under the gadgets tab?" Eman235/talk 23:21, 3 February 2015 (UTC)

... and then a bit later (as very few people read the documentation): "what are all those 'rollback' links doing in my watchlist? let me turn that off". :) In other words, IMHO, if someone wants to deal with vandalisms by using the rollback feature, he or she will eventually become aware of its existence and ask for it. That's how I see it; of course, I might be totally wrong. — Dsimic (talk | contribs) 23:33, 3 February 2015 (UTC)
(kinda on a tangent now) ...and then a little bit later, on the admin side "Hey look, this user is using rollback inappropriately, but we can't remove it unless we block them." We may have that problem if we have a user using the rollback gadget, and it turns out that their rollbacks are just plain disruptive, but their rollback permissions can't be revoked unless they're blocked. Then again, I may be wrong as well. Epic Genius (talk) 23:51, 3 February 2015 (UTC)
We can't turn off Twinkle or the undofunction if users are abusing those either, and they have the same or better capabilities than rollback. That's kind of the whole point. Beeblebrox (talk) 00:30, 4 February 2015 (UTC)
But at least rollback can be used on every single page, including watchlists, recent changes, history, contribs lists, diffs, etc. TW can only be used from contribs pages or diffs, and undo can only be used in history pages and diffs to my knowledge. Rollback is more powerful. Epic Genius (talk) 01:16, 4 February 2015 (UTC)
I'd be ok with an "autorollback" approach or an "autoavailable-to-be-activated" approach. I'd personally go with three months or longer, though, because I'd like to see it limited to people with at least a certain amount of demonstrated commitment. But as @Monty845 says above, we don't have to discuss exact criteria here. StevenJ81 (talk) 16:43, 4 February 2015 (UTC)
I, too, would be OK with "autorollback" so long as there is a box to check on the Gadgets page for those who don't want to use it. –Fredddie™ 20:28, 4 February 2015 (UTC)

Make Huggle a right?

(This may seem to stem from "Make Twinkle a right" but actually comes from "remove rollback?")

I think a solution to the worries some have been expressing would be to make Rollback a gadget, and to give Huggle a permission system like AWB. Comments? Eman235/talk 22:31, 3 February 2015 (UTC)

That's more or less what I've been saying, but you may have expressed it more clearly. AWB doesn't seemto have a big problem with vandals getting access, there's no reason other tools couldn't do it the same way. Beeblebrox (talk) 23:14, 3 February 2015 (UTC)
That doesn't really alleviate many of the worries of the some of the objectors at all. Here, I have a counter-suggestion for you... Tharthandorf Aquanashi (talk) 01:13, 4 February 2015 (UTC)
You can't really do that, for the same reason as I mentioned for Twinkle above. Huggle is open source and can be forked into a version that bypasses a permission system. —Миша13 10:59, 4 February 2015 (UTC)

Merge the functionalities ...

... of rollback and Huggle, remove the current "rollback" function, then allow Huggle to be available for general use so long as a user that wishes to use it gets an administrative go-ahead

(Note: I'm not discarding my previous suggestions. I'm merely proposing another alternative.)

Very similar to the proposal above, except the rollback and Huggle functionalities would both merge into Huggle, and then the current "rollback" would be tossed. Then, Huggle would be made available for use so long as an administrator gave the go-ahead to the user who wished to use it. Tharthandorf Aquanashi (talk) 01:20, 4 February 2015 (UTC)

@Tharthan: Could you please shorten the section heading? It's rather long... — MusikAnimal 02:21, 4 February 2015 (UTC)
@MusikAnimal: Sure, but what do you suggest for it? I can't really think of anything good or descriptive that fits it. Tharthandorf Aquanashi (talk) 03:28, 4 February 2015 (UTC)
Good idea, except some might want rollback without Huggle. Eman235/talk 01:42, 4 February 2015 (UTC)
Twinkle is merging with "FurMe" soon, so perhaps better overall browser support can be developed during that merger. Or, depending on the outcome of this RfC, a "Huggle Lite" could be developed that primarily focused on the rollback function or something of that sort. Tharthandorf Aquanashi (talk) 01:56, 4 February 2015 (UTC)
The huggle devs, like the creators and maintainers of ther tools, are free to come up with new standards for access to their tools should this change occur. I have no problem with that. They never should have tried to shoehorn their prescreening into requests for rollback in the first place, they should control access with their own criteria, the way AWB does. Linking these two issues distracts form the real discussion, which is not and should not about huggle at all. Beeblebrox (talk) 02:01, 4 February 2015 (UTC)
This seems a little extreme. Why require people to install extra software/scripts to use something already built into MediaWiki? Mr.Z-man 02:38, 4 February 2015 (UTC)
It may be a bit extreme, but so was the initial proposal of this RfC. Tharthandorf Aquanashi (talk) 02:41, 4 February 2015 (UTC)
Obviously we differ there, I don't see making a user right that can already be had in other forms more accessable an extreme stance at all. I also don't think posting wild new proposals just because you believe that simple change to be extreme is helpful in moving toward consensus. Beeblebrox (talk) 03:13, 4 February 2015 (UTC)
There seems to be no consensus on this at the moment, and none of my proposals are particularly wild as far as I can see (unless I'm missing something about them). They're just alternatives. Plus, people are already pointing out that Huggle's equivalent to rollback is not as good. So, I thought... this could kill two birds with one stone. Tharthandorf Aquanashi (talk) 03:25, 4 February 2015 (UTC)
Why would we need a whole bunch of clunky JavaScript code and a box with dozens of buttons, when we already have a simple utility that does the job very well? Swiss knives with integrated toothpicks are great, but they aren't a reason to ditch plain good old toothpicks. — Dsimic (talk | contribs) 02:59, 5 February 2015 (UTC)
Come now, you are just grasping at straws at this point. If you are going to go the "If it ain't broke, don't fix it" route, then you would oppose this proposal entirely. Tharthandorf Aquanashi (talk) 03:05, 5 February 2015 (UTC)
Actually I do oppose it, see my vote above. :) — Dsimic (talk | contribs) 03:11, 5 February 2015 (UTC)

Rename rollback user group

I'll copy and paste my thought from the Discussion section (before the Suggestions section was made):

An alternative to this proposal is to simply rename the user right to something like "vandal fighter" (no offense to those who initiated that proposal, I just think it's a fitting name). That is, vandal-fighter gives you a quicker way to undo consecutive changes, it's available on your watchlist, and grants access to all the anti-vandal software. Twinkle and undo can't do any of those (keyword FAST). More at Help:Reverting. Basically if we just renamed the user right we'd rid the concern about redundancy, avoid these CSS/JS hacks, none of our procedures at PERM would need to be modified, those who already have rollback would be unaffected, developers don't have to update anti-vandal software – essentially still allow things to operate in the same way that they do now. Admins who don't want rollback links can add CSS to remove them.

To further clarify, rollback has little use beyond anti-vandalism efforts (quick, leaves no edit summary, marks edit as minor, available on watchlist), which is not the case for Undo and Twinkle (requires multiple clicks, offers to supply edit summary, not available on watchlist where edit warriors could more easily take advantage of it). If you're using an older browser that Twinkle doesn't work on, you can use Undo, or of course still request rollback – but it's going to be assumed you're planning to be involved in counter-vandalism, or you've been around long enough with good standing that we don't need to be concerned about misuse.

Personally, I think things are fine the way they are now, but if we rename the right we can at least get rid of most of the concerns brought up by the supporters. — MusikAnimal 01:59, 4 February 2015 (UTC)

Notes

  1. add .mw-rollback-link { display: none !important; } to your common.css
I'm already using that, but I think it's kind of backwards that I'm forced to go find scripts to block a user right that I do not want or need. When it was unbundled from the admin package it should have actually been unbundled and made opt-in only. Any admin who wants it can grant it to themselves in a matter of a few seconds. Beeblebrox (talk) 02:21, 4 February 2015 (UTC)
Most of our tools are for anti-abuse, it makes sense rollback is one of them. However if there's consensus the "vandal-fighter" right could certainly be opt-in even for admins. Note we could also add "remove rollback" (or remove vandal-fighter, whatever it will be called) as a gadget, if that makes it easier. — MusikAnimal 02:27, 4 February 2015 (UTC)
I really like this suggestion. Hear, hear! Tharthandorf Aquanashi (talk) 02:29, 4 February 2015 (UTC)
rollback has little use beyond anti-vandalism efforts (quick, leaves no edit summary) N.B. There are also scripts that can add a summary to your rollback button (I have one myself).Also, the "rollback" user right is named as such in other Wikimedia projects, so I don't think this user right renaming, especially to "vandal-fighter", will fly well with WMF, since we should try to assume good faith and not get violent. Maybe "reverter"? Epic Genius (talk) 03:59, 4 February 2015 (UTC)
According to mw:API:Rollback an edit summary can apparently be supplied, but what I was getting at is it's generic by default because in acceptable scenarios rationale is not needed on this wiki. Any good-faith edit should not be reverted using rollback. The "vandal fighter" recommendation was just because that's what rollback is usually for, especially given the added access to anti-vandal tools, but any fitting name will do. "Reverter" seems good but perhaps misleading as some might think they'll need it to revert edits. By the same token some might think they will need "vandal fighter" to fight vandalism. Seemingly the only truly fitting name is "rollback", as that what it grants, the ability to perform system rollback – something Twinkle and Undo don't offer. Hence why I think things are just fine the way the are...As far as I know user rights can be renamed locally, as specified at Special:ListGroupRights. Rollback is only on certain wikis as it is now. The validation with the backend I believe is done with permissions, so we'd be changing the name of the user group, not the permission. E.g. global rollbackers would still be able to rollback here. This would be tantamount to how "reviewer" was recently changed to "pending changes reviewer". I could easily be wrong about all this, though. — MusikAnimal 05:16, 4 February 2015 (UTC)
I suppose you're right about the "vandal-fighter" name. However, wouldn't the right itself still be "rollback"? (Like how "autoreviewer" was renamed a while ago to "autopatrolled", but it still shows up in popups as "autoreviewer".) Epic Genius (talk) 15:09, 4 February 2015 (UTC)
This RFC is going all over the place. We have "User Groups" and "Permissions"..they are different things, you can see the list here: Special:ListGroupRights, users can be a member of multiple groups, the groups add the permission to a user. — xaosflux 16:33, 4 February 2015 (UTC)
Yep, and it's the user group that can be renamed (they in fact differ wiki to wiki), while the permissions (also called rights) will go unchanged. My rename proposal is more about finding a common ground between both sides of this RfC. However after giving it more thought I can't say I'm too much of a fan of renaming either. I think I'm ready to cast my oppose !vote. — MusikAnimal 16:41, 4 February 2015 (UTC)
Quite frankly, "vandal-fighter" sounds so lame. — Dsimic (talk | contribs) 03:01, 5 February 2015 (UTC)

"Vandal Rollback" gadget?

Here's yet another option, we could:

  1. Make a gadget called "Vandal Rollback", (or "Vandal Fighter", as above) similar to Twinkle's "Rollback (VANDAL)" button. This would work with all browsers and show up in the same places as Twinkle's buttons do. (Alternatively, we could turn Twinkle's Rollback module into a standalone gadget that works on all browsers.)
  2. Keep the current Rollback permission process, maybe renaming it "Vandal Rollback Plus" or similar. Huggle would require this to function.

I think this would kill two birds with one stone -- those not in the rollbacker usergroup could only rollback in contribs lists, edit histories, and diffs, and just using the Rollback gadget wouldn't grant Huggle use. Eman235/talk 20:49, 4 February 2015 (UTC)

Please don't get me wrong, but I really don't see the benefits of making it more complicated. And "vandal <something>" would sound lame. — Dsimic (talk | contribs) 03:06, 5 February 2015 (UTC)
Category: