Jump to content

Wikipedia talk:Rollback/Archive A: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Discussion: and my spellschecker seems borked as well..
Line 71: Line 71:
#'''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. [[User:FourViolas|FourViolas]] ([[User talk:FourViolas|talk]]) 15:11, 2 February 2015 (UTC)
#'''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. [[User:FourViolas|FourViolas]] ([[User talk: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? [[User:Squinge|Squinge]] ([[User talk:Squinge|talk]]) 15:19, 2 February 2015 (UTC)
#:So you think giving newbies access to something that is less powerful than they already have (ie Undo) is dangerous? [[User:Squinge|Squinge]] ([[User talk: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. [[User:Cenarium|Cenarium]] ([[User talk:Cenarium|talk]]) 20:01, 2 February 2015 (UTC)
#'''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 Wikipedia 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. --[[User:Tryptofish|Tryptofish]] ([[User talk:Tryptofish|talk]]) 15:48, 2 February 2015 (UTC)
#'''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 Wikipedia 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. --[[User:Tryptofish|Tryptofish]] ([[User talk: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. [[User:Squinge|Squinge]] ([[User talk:Squinge|talk]]) 15:54, 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. [[User:Squinge|Squinge]] ([[User talk:Squinge|talk]]) 15:54, 2 February 2015 (UTC)

Revision as of 20:02, 2 February 2015

Should rollback be changed form 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 Wikipedia. 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. Wikipedia: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)[reply]
  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)[reply]
    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)[reply]
    If it was removed altogether, it would break Huggle and other tools that rely on it. Squinge (talk) 09:45, 2 February 2015 (UTC)[reply]
    @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)[reply]
  3. Support as long as anonymous users can't use it. Richard75 (talk) 23:00, 1 February 2015 (UTC)[reply]
  4. Support This seems logical and I agree with the proposer's rationale. Everymorning talk 23:10, 1 February 2015 (UTC)[reply]
  5. Support as there has been no need for this group for a very long time. — {{U|Technical 13}} (etc) 23:19, 1 February 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  8. Support per Steel1943 comment. IPadPerson (talk) 00:25, 2 February 2015 (UTC)[reply]
  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)[reply]
  10. Support Personally for my first 500 edits I did vandalism patrol to understand how Wikipedia 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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    • 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)[reply]
    • 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)[reply]
  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)[reply]
  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(Come Talk to Me!) 14:30, 2 February 2015 (UTC)[reply]
  17. supportmight be a good idea--Regisaurusjacobi 15:01, 2 February 2015 (UTC)
  18. 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)[reply]
  19. 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)[reply]
  20. Strong support, per proposer. APerson (talk!) 15:47, 2 February 2015 (UTC)[reply]
  21. 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)[reply]
    You don't even need to edit the restoration version - just diff and click Undo! Squinge (talk) 19:27, 2 February 2015 (UTC)[reply]
    Does that work with reverting multiple edits? —George8211 / T 19:34, 2 February 2015 (UTC)[reply]
    Yes, and by multiple users too - give it a go at the sandbox. Squinge (talk) 19:37, 2 February 2015 (UTC)[reply]

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)[reply]
    What exactly are we revoking if the function can be done without the tool/gadget? Steel1943 (talk) 23:33, 1 February 2015 (UTC)[reply]
    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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
    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)[reply]
  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 Talk 03:41, 2 February 2015 (UTC)[reply]
  5. Oppose. This is a right that should be exercised by experienced users. -- Ssilvers (talk) 05:07, 2 February 2015 (UTC)[reply]
  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 (talk | contrib) 05:29, 2 February 2015 (UTC)[reply]
  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\talk 05:56, 2 February 2015 (UTC)[reply]
  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! speak to me...review me... 07:03, 2 February 2015 (UTC)[reply]
    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)[reply]
  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)[reply]
  10. Oppose per all above. Hafspajen (talk) 08:03, 2 February 2015 (UTC)[reply]
  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 ✔Tea time 09:14, 2 February 2015 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  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 Wikipedia 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)[reply]
    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)[reply]
    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)[reply]
  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 Wikipedia 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)[reply]
  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)[reply]
  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 Discuss 19:04, 2 February 2015 (UTC)[reply]
  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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 talk 23:45, 1 February 2015 (UTC)[reply]
  • @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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
@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 talk 04:29, 2 February 2015 (UTC)[reply]
@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)[reply]
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 Talk 03:43, 2 February 2015 (UTC)[reply]
  • 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)[reply]
  • 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 (talkcontribslogs) 13:44, 2 February 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Ah, so there's apparently no functional difference, script-wise, between Undo and Rollback then. Squinge (talk) 14:33, 2 February 2015 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
  • 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)(c)(e) 17:51, 2 February 2015 (UTC)[reply]
  • 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 jus gets in the way. Beeblebrox (talk) 19:50, 2 February 2015 (UTC)[reply]