This feedback round is closed. A big thanks to everyone who participated! A summary of the results can be found on the project page.
Update March 29, 2019: The confirmation prompt has now been implemented, but it only shows if you want it to:
In all wikis except German Wikipedia, the confirmation prompt is switched off by default. If you want to use it, you can turn it on individually.
On German Wikipedia, the confirmation prompt for rollbacks will be deployed on April 4 (estimated date) and will be switched on by default. Users on dewiki who want to rollback quickly can turn it off individually in their user settings. This can already be done in advance.
A wish from the German Technical Wishes survey 2017 describes the problem that sometimes users who have the rollback right accidentally click the rollback instead of the thank you link, which can lead to very unpleasant misunderstandings.
After several user interviews, the Technical Wishes team came to the conclusion that this is how the rollback function is being used:
Most people use the rollback function via the diff view.
The majority of users do singular rollbacks. Nonetheless, there are some people who specifically roll back multiple instances of vandalism in one go.
Based on these insights, an idea for a solution was conceptualized.
Everyone who has rollback rights is invited to have a look at the proposed solution and share their comments in the feedback section on this page.
EDIT: A big thanks to every single person who took the time to comment. Your feedback really helps us finding a solution.
Please note that we’re still in the research phase and this feedback round is part of understanding how rollback works in international communities.
If you have contacts to smaller wikis, it would be great if you could spread the word about this feedback round.
Please elaborate your assessment in a few sentences, if possible.
Screenshots are always welcome.
If you have any remarks about this feedback round itself, please let us know on the talk page.
Don't forget to sign your comment. ~~~~
Question: Does the proposed solution solve the problem without disturbing my workflow?
If yes, what is good about the solution? If no, please describe why the problem remains / where your workflow is being disturbed.
Yes, because the obvious solution is obvious. I would rather spend an extra five seconds saying "no" to an accidental click than spent two minutes reverting my revert and apologizing to the user. Primefac (talk) 13:52, 19 April 2018 (UTC) For what it's worth, I missed the "removing from lists" bit, and I concur with the editors below me regarding its removal (i.e. I don't like it). Primefac (talk) 14:14, 19 April 2018 (UTC)[reply]
The idea of a confirmation dialog is a good one (enwiki has a default-on gadget that does something similar), but I feel very strongly about removing the rollback link from list views; I don't know about anyone else, but I use rollback regularly from my watchlist on certain heavily-vandalized articles and user talk pages, I've written mass-rollback scripts that depend on the rollback link being there, and I almost never use rollback from the diff view. I feel that the removal of the rollback link from list pages should be decoupled from the confirmation dialog--I like the confirmation dialog and would want to have it, but I definitely don't want to lose the rollback links on list views for it. Writ Keeper (talk) 13:56, 19 April 2018 (UTC)[reply]
Confirmation should be opt-in, not opt-out (I have opted-in for mobile, but not desktop). I'd also agree with Writ Keeper and state a bit more strongly that it absolutely should not be hidden by default from lists: that is perhaps the most useful part of rollback for me, and I'm assuming many other users. I agree it should be decoupled and making it opt-in is also especially important given the impact it would have on Writ Keepers script, which is one of the most frequently used anti-vandal scripts by admins on en.wiki. TonyBallioni (talk) 14:04, 19 April 2018 (UTC)[reply]
I've already had a bit of computer magic installed for a while that causes the popup to happen. It's super useful, especially when viewing desktop version from mobile. Removing the link in lists may be alright as an opt-in feature, but if you use popups, you can still save time by previewing the diff from a list, and the rollbacking from a list, rather than having to click through to the diff. Rollback from list is also super useful when you've identified an obvious and active vandal, but 20 of their edits are current, and you can just right-click open new tab rollback 20 times instead and then close all the tabs. It's not often you find a situation where you have enough confidence to mass rollback without even looking through each diff, only egregious and prolific VOAs, but when you need it it's good to have. GMGtalk14:13, 19 April 2018 (UTC)[reply]
I oppose any changes to what I see now. I can rollback from diff view and list view without having to confirm. I use both frequently. Misclicks are too rare for me to want to confirm. I also disagree that rollbacks are rare. Not for me.--Bbb23 (talk) 14:38, 19 April 2018 (UTC)[reply]
I'm surprised that this is that big of an issue, and should probably be solved by the user being more careful rather than changing it for everyone. Perhaps deWiki uses thanks more than en or others? I shorten my rollback and thanks links to a single letter and don't have much of an issue. At any rate, I basically agree with the above, answering "no." Asking for confirmation is reasonable, but to avoid disruption I'd suggest making it default only for future rollbackers while leaving it unchanged/opt-in for current rollbackers. I disagree entirely with hiding the links throughout the interface — that defeats the whole purpose and use of rollback — but I suppose having that default to off but offering it as an option is fine. Regardless, the current state of affairs should remain the default for all sysops. ~ Amory(u • t • c)14:56, 19 April 2018 (UTC)[reply]
I use rollback a lot. For me, rollback is useful for every view except diff-view, where I have literally never used it. I like the idea of an opt-in confirmation for those with fat fingers, and I like the idea of a (separate) option about where to use rollback links. I think the default might be a good idea, but it should not be mandatory and I won't be using it. zzuuzz(talk)15:41, 19 April 2018 (UTC)[reply]
I strongly agree that the diff warning and list view preferences should be separate, since they are two distinct use cases and different people will have different problems. I have no strong view about what the default should be for new rollbackers and admins but I do agree that existing ones should not have the behaviour changed by default. BethNaught (talk) 17:35, 19 April 2018 (UTC)[reply]
The suggested default is essentially the opposite of what I would expect. I rarely use rollback from the diff view, it's almost always from the list view (usually someone's contributions). Rollback is valuable for quickly reverting edits, particularly in large numbers, this usually happens from list views and asking for confirmation would get in the way. Removing rollback from RecentChanges would be particularly strange given that the main use case for that page is countervandalism. I've never heard of someone accidentally reverting an edit in this way. I could live with the change if I could turn it off but I would suggest that the default be the existing behaviour as a lot of rollback users are likely to turn it off. Hut 8.518:37, 19 April 2018 (UTC)[reply]
Not very much active in antivandalism, but when I use rollback usually from diff view as I want to see what I am reverting. I've misclicked on watchlists and thus have the rollback link disabled there. Confirmation would negate the main benefit of rollback, that it quickly removes the problem edit from the page, and even a millisecond difference stacks up with many delayed rollbacks and high traffic pages. Jo-Jo Eumerus (talk, contributions) 20:13, 19 April 2018 (UTC)[reply]
I oppose this change - I revert via Contribs all the time so having a confirmation box would be a pain especially when I know it's blatant vandalism, Diff view is also helpful as I like to see the edit before I revert, One issue I do have however is the accidental watchlist rollbacks but I occasionally revert vandals via the watchlist so again removing it or having a pop up box wouldn't really help, Personally I feel as a whole the confirmation box would be more of a hinderance than of help, Thanks, –Davey2010Talk20:26, 19 April 2018 (UTC)[reply]
I oppose this change. The rollback feature works well for me as it is, and this "solution" seems to be to be totally unnecessary. It would make rollback almost exactly as labor-intensive as "undo", and make it that much more time-consuming to rollback vandalism. Any changes that are made should definitely be opt-in, and not opt-out. Beyond My Ken (talk) 04:55, 20 April 2018 (UTC)[reply]
If you want to take two steps to undo something, there is another feature you can use - the undo button. If you want to not see rollback links everywhere, you can hide them with js. If this is implemented, it should be opt-in not opt-out. As someone who often mass-reverts vandalism and spam, this change would reduce the efficiency of my workflow in half and present no added benefit. – Ajraddatz (talk) 05:10, 20 April 2018 (UTC)[reply]
If you really want to do this, I suggest we just remove the rollback function altogether. This just makes rollback useless. — regards, Revi09:17, 20 April 2018 (UTC)[reply]
As an example - You don’t compare diffs when you revert all of contribs from ko:특:기여/Sssssssssssssssssssssssssssssssssssssssssssssssssssss. This frequently happens and having to 1. browse to diff view and click confirm or 2. have to browse to preferences and enable Countervandalism mode for ALL wikimedia wikis do more harm than good. — regards, Revi22:09, 24 April 2018 (UTC)[reply]
It could look something like this, but don't get hung up on the details I feel a much better solution would be to clean up the layout of lists. Currently they are a mess (even if we all got used to that mess). Improving the readability of lists and ensuring that actions are always in the same place and potentially use icons and colors to mark "dangerous" options would most likely go a long way to avoid misclicks. Sebari (talk) 06:02, 20 April 2018 (UTC)[reply]
Love this design a lot. Unfortunately, then we will have 3 different list types to maintain. Will take years to roll this out honestly and cause lots of community conflicts. —TheDJ (talk • contribs) 07:38, 20 April 2018 (UTC)[reply]
I oppose this idea. The value of rollback (vs undo, vs edit-old-revision) is exactly the one-click nature. No fuss, no having to switch to another tab to click something else or get rid of yet another popup window, just poof!-edit's-gone. And that I can do it when running through my watchlist (I specifically watch pages in order to easily catch and quickly undo vandalism!) or user contributions (I specifically look at a user's contribs after seeing one vandalism in order to see if there is a pattern). As others have said, by the time I'm at a diff page, I already have multi-click options available for this action. Using popups, it's easy to see the edit without going to an actual diff page, and again, the value is not having to go through more actiouns to be able to get to the point of getting rid of vandalism. I could see this being a gadget or other interface option, like the one we already have for rollback on mobile devices if people feel they need wikipedia to save them from their own mistakes, but it seems like overkill for devices where mouse cursors are so well-defined and likely mouse-positioned before the click action. This is unlike mobile devices where small touch-screens make it less certain where the click will land. We already have a mobile-specific gadget for rollback confirmation. DMacks (talk) 06:10, 20 April 2018 (UTC)[reply]
Some of the objections above do not address the fact that the proposal includes a preference to opt-out of the change so rollback would work as it does now. Setting a preference seems easy enough. Is the concern for other rollbackers who may not notice a relevant announcement? The proposal is fine for me as I would set the preference. Defaulting to a confirmation is desirable. Any new rollbackers should be expected to read the documentation to understand what is involved, and that will explain the preference. I almost always use rollback from a diff, but will sometimes do a mass rollback from a user's contributions. Johnuniq (talk) 06:13, 20 April 2018 (UTC)[reply]
I perform rollbacks from the recent changes or article history quite frequently and would not like this functionality to be removed entirely. If it must be removed, there needs to be an opt-in that works without JavaScript. --Gryllida06:25, 20 April 2018 (UTC)[reply]
I think it would not be a bad idea to have the presence of those links configurable. I wouldn't mind only being able to have them on a diff really. Wether to switch that by default for existing users is a different story however (i'd just ask each individual user to choose with a one time modal). Also it won't exactly help with the problem here that if you use Twinkle, everything still jumps around on the diff page. —TheDJ (talk • contribs) 07:31, 20 April 2018 (UTC) (reply)
Oppose. I use rollback a lot. Having to confirm each time I want to rollback a vandalism or spam is like going back to the undo function. If anyone wants to opt in for a warning before rollbacking functionality that's fine for me, but making that the default that I'd not support. Thanks. —MarcoAurelio (talk) 09:05, 20 April 2018 (UTC)[reply]
Comment I do not support the proposed changes as new defaults.
The issue in the diff view is that the rendering when you click the thank that it expands, so you can often hover over a link, and then it redraws and where you are clicking becomes the rollback link. To me it seems that this is simply positioning, and whitespacing, rather than a change of function or process. Get the rollback link away from being buried. I submitted a ticket with pictures at phab:T158918 long ago.
Further, as someone who does lots of xwiki spam and coi work, having to set a new default per wiki would be abysmal. Working on xwiki spam means you can be opening multiple diffs on many wikis, so having to then do additional clicks is going to be totally annoying. [From a xwiki list (tool or at meta), one to open the diff, one to rollback, so adding another is going to get grrrr, especially as I would rarely foul it.] If you wished to have this additional behaviour as an option for people to switch on, then that is fine. If we are having a change of process I ask that you invert your default mode to be active, and the switch to be safe. — billinghurstsDrewth09:09, 20 April 2018 (UTC)[reply]
Comment I do not support the proposed changes as new defaults. Might as well simply use "undo" if this is implemented. Yes, occasional accidental rollbacks may happen but you usually know you've done it and I've never seen anyone get upset when it is quickly reverted. The entire point of rollback is reduction of mouse clicks etc, so adding confirmation boxes and other hoops negates its purpose. - Sitush (talk) 10:55, 20 April 2018 (UTC)[reply]
Making 'non-vandalism mode' default to all rollbakers in all wiki seems strange because we use the rollback right to fight vandalism. Non-vandalism mode makes the function inconvenient to users who use it a lot. In the German Wikipedia, the rollback right is granted with other rights(Sichter group), so there can be Sichters who don't use the rollback function often. In the Korean Wikipedia, the rollback right is granted independently(Rollbacker group), so those who request the right use it a lot. Making non-vandalism mode opt-out for all wiki is not a good solution. Bluemersen (talk) 11:05, 20 April 2018 (UTC)[reply]
Probably it solve the problem, but I think it isn't practical, especially rollbackers usually users with highly interest on fighting vandalism and use rollback button heavily, so confirm every rollback not practical to any of them! I suggest to apply it as a feature instead a default -if it easy to apply it-. Also we uses scripts that depends upon exist of rollback button on contributions log. Is there any expected percentage to these spontaneous errors? --Alaa :)..!11:23, 20 April 2018 (UTC)[reply]
The point of the rollback function is to use it for fighting vandalism. It's not supposed to be used for undoing good-faith edits, so we should probably assume vandal-fighting mode is what people want? Accidental rollbacking is, as far as I'm aware, not considered a big issue on the wikis where I'm mainly active (that is, we consider it a small problem to revert accidental rollbacking, probably less work than having to confirm it). Sure, add a confirmation prompt if people want one, but don't make it – or removing it from recent changes – the default. /Julle (talk) 11:26, 20 April 2018 (UTC)[reply]
I could be mistaken, but I wonder if this isn't a case of trying to internationally solve what's mainly a local problem. My understanding is that German Wikipedia is more an exception than the rule when it comes to how rollback rights are assigned, compared to other Wikimedia wikis. It's possible that you shouldn't try to generally change the rollback function for everyone based on wishes from the German community. /Julle (talk) 11:46, 20 April 2018 (UTC)[reply]
The default option should be the "vandalism mode". You don't need rollback rights if you don't revert vandalism. I know users who by mistake press "revert" button, for example when using mobile phone. They could then switch to "non-vandalism mode" if they desire. Stryn (talk) 11:32, 20 April 2018 (UTC)[reply]
The default option for most editors is not to have access to this function already, for those that ask for it enabling all functionality should be the default. I'm fine with having an opt-out of certain displays and and opt-in to enabling a confirmation. — xaosfluxTalk11:50, 20 April 2018 (UTC)[reply]
Right problem but wrong solution. The solution is surely to put the Rollback and Thank farther away from each other on interfaces...? I agree with the premise that the currently placement of Rollback next to Thank leads to misfires but I also agree with comments above that Rollback is primarily useful because it's one-click. If this design proposal goes ahead, please at least make "one-click" and "display in lists" two separate options. I mainly use Rollback from Watchlist and History reviews because I can preview edits using Popups. Deryck C.13:01, 20 April 2018 (UTC)[reply]
I have accidentally reverted someone before when I dropped my tablet and grabbed on to it exactly where the rollback link was, so I can agree that this is a potential problem. That said, I don't agree with hiding the rollback links in list views as they have a lot of utility there. I think a simpler solution to the proposed one would be to leave all the interface elements exactly where they are right now, add confirmations to all of them, but make it so that ctrl-clicking the link to open it in a new tab does not require the confirmation. This solution minimises change in the interface (no users saying "Where have my rollback links gone?"), keeps the functionality of all rollback buttons the same, solves the problem of accidental reverts by using confirmations, and provides users who wish to mass revert, or revert more quickly, with an easy mechanism to do so. A similar solution to this is used in the media viewer: clicking the image opens the media viewer, but ctrl-clicking skips the media viewer and opens the file page in a new tab. Also, this shouldn't be a user preference; there are too many user preferences already, and more complexity there is not a good thing. --Deskana (talk) 13:26, 20 April 2018 (UTC)[reply]
I think the options should be implemented separately: one checkbox for enabling/disabling the confirmation prompt, and another checkbox for showing/hiding the rollback link in lists. FlyingAce (talk) 13:37, 20 April 2018 (UTC)[reply]
I very, very strongly oppose this. Rollbacks primary (and in my opinion, singular) function is for vandalism. I think the assertion that rollback is primarily used via diffs is absolutely incorrect as well. I know this is anecdotal evidence but I know for myself and many other vandal fighters, we rollback from contribs or recent changes (I verify first that the contribs are vandalism if I don't know for sure.) This adds another step and prevents effective anti-vandalism work. I also don't think accidental rollback is all that common, I've definitely made mistakes rolling something back but it wasn't a mistake that would have been caught even if I'd had the confirmation. Chrissymad (talk) 14:03, 20 April 2018 (UTC)[reply]
I strongly oppose any changes. Rollback is a tool for anti-vandalism; people who have it need it for that purpose. Removing it from lists and adding a confirmation box by default will, in my opinion, not be beneficial. There are currently user scripts (on En-wiki, they can probably be copied globally somehow) that show confirmation messages, if the user wants them. I personally use one on the English Wikipedia, but not elsewhere. Vermont (talk) 14:06, 20 April 2018 (UTC)[reply]
No way. If I wanted an extra confirmation step or an extra step away from contributions/history, I'd use the "undo" function. I regularly use rollback from recentchanges, watchlist and contributions. Just few days ago I rolled back hundreds of contributions from one vandal's contributions page, I would be very angry if I were forced to perform extra steps for such a repetitive and routine task. People who don't want to use the rollback button can simply hide it or ask to be deflagged. Nemo15:06, 20 April 2018 (UTC)[reply]
If someone feels that [rollback] links are too prominent and/or do not look dangerous, then their visual size can be decreased with CSS, they can be made more “menacing” in appearance, or something like it. Modifications of MediaWiki:Common.css by community consensus on each separate wiki would be sufficient (which would leave to a regular vandal fighter an option to return to the traditional look with a personal CSS). Tuning CSS is cheap and less prone to software errors than adding extra dialogs. Please, don’t change how the server software works – quick revert is our boon in the combat against baddies. Incnis Mrsi (talk) 16:36, 20 April 2018 (UTC)[reply]
No, this is a bad idea and a case of extreme software bloat. There is the simple technical ability to have confirmable on those buttons already. Add it as a gadget for users to turn on, recommend it when adding a rollback right to someone and move on. No need to have WM-wide decisions on this when the code is literally three lines.
// Add a rollback confirmationmw.loader.using(['jquery.confirmable'],function(){$('.mw-rollback-link > a').confirmable();});
Oppose per some others above. This is a really bad idea, and would require a lot of work cross-wiki to restore a very useful function; and being able to rollback directly from a list is a very useful function. Courcelles02:13, 21 April 2018 (UTC)[reply]
Misfires happen, so an optional confirmation dialog makes sense. Regarding list vs diff view: Maybe it is not clear, but many people use w:en:WP:POPUPS to view diffs from list views. This is what makes rollback so useful there. Having to click through one by one to view the diff and rollback would slow down your workflow significantly. Some people don't use Popups, in which case perhaps it does make sense to only have rollback in diff views, since in general you would want to see what you're reverting :) Though sometimes you might still want to mass-revert edits by sockpuppets, or the like, without viewing diffs, so overall I would oppose removing rollback from list views. Thanks for seeking our feedback. — MusikAnimaltalk12:43, 21 April 2018 (UTC)[reply]
Oppose any change and prefer the status quo. The background of this supposed problem is also incomplete. No statistical evidence of misclick is given, it is only asserted, and I disagree with that conclusion from the beginning. I have literally used rollback thousands of times and cannot remember mere 10 instances of misclick. This appears to be issue of one wiki and should be solved locally at that level without tempering with the global setup, which will impede the speed and easiness of fighting the determined vandals on the English Wikipedia. –Ammarpad (talk) 01:54, 22 April 2018 (UTC)[reply]
Strongly oppose Implementing this would make rollback all but useless as far as I am concerned; I almost always use it from list view (combined with a diff viewing script) and value the very fact that it is one-click - if I'm going to be forced to go to the diff itself and provide confirmation, I may as well use the Undo function instead. This is a solution in search of a problem. If the issue is that people are clicking "rollback" instead of "thanks", just move the links so they are further apart. Yunshui (talk) 08:17, 23 April 2018 (UTC)[reply]
I do occasionally misclick, but that is mostly from trying to click the page than the thanks link. I do have a script to have confirmation in certain lists, but by default it should be instant and definitely show up on list views. For those who have problems there are many solutions already, anyhow. Galobtter (talk) 08:27, 23 April 2018 (UTC)[reply]
Oppose: I use the rollback function rarely. But when I use it (in contrast to undo) I rollback usually from the contributions page because it allows to undo greater series of vandalisms quickly without hassles. Popups would make it harder. And opt-out configurations would have to be done on each project which is not convenient. Please keep it as it is. --AFBorchert (talk) 08:31, 23 April 2018 (UTC)[reply]
Oppose - I mostly do mass rollbacks from the lists (typically the contribs-list). I never do mass-thanks, though, and if I thank an editor I would do that on the diff specifically. Remove the thank-button instead of the rollback button from the lists is a more logical choice. --Dirk BeetstraTC (en: U, T) 08:42, 23 April 2018 (UTC)[reply]
It seems that the German WP has bundled the rollback right with "sichter" (reviewer) right which is given automatically after a certain number of edits. If you have extra buttons you don't need and then accidentally click them, of course that's a nuisance. In other wikis users have to specifically ask for the rollback button because the only purpose of it is to make it easier to revert vandalism. (Could it also be that the German WP has less vandalism in general because of flagged reviews?) I use rollback all the time and I'm opposed to changes to its default settings. It might be useful to some users as an opt-in. -Kyykaarme (talk) 10:00, 23 April 2018 (UTC)[reply]
There are two questions here. First, should rollback require confirmation? Second, on what pages should rollback links appear. Personally, I don't think change is needed (whenever you mis-click on a rollback link, you just rollback your own mis-click, problem solved). I typically use rollback from lists (often) and from diffs (rarely). On lists, I often check the diff via popups, but sometimes just mass-click all rollback links. Requiring confirmation completely destroys the use of rollback for me. Users who can't deal with the rollback links should just ask to have the rollback flag removed. The "thank" link could also be removed or made optional for those who have problems with both links being present. As mass thanking is a less common and time critical task than mass rollback, maybe losing the thank button on certain pages would not be a problem. Kusma (talk) 11:33, 23 April 2018 (UTC)[reply]
Oppose any change of the default. Confirmation/hiding of links all make rollback not fulfil its primary function (hassle-free one click reverts) so should be only turned on for those who have rollback but don't want it. Kusma (talk) 11:37, 23 April 2018 (UTC)[reply]
Oppose The whole point of rollback is its single-click functionality - requiring a second step of confirmation would eliminate its usefulness. The current status should remain the default. Deli nk (talk) 15:38, 23 April 2018 (UTC)[reply]
No, or Oppose as proposed, whichever is clearer. The solution is a good start, but having to click on the diffs is very tedious. I would keep the confirmation dialog, but enable by default the rollback links in the list view, since being able to rollback from the contributions page is very useful in reverting vandals. Removing it from list view defeats the purpose of having rollback. I think the user should have options to (1) not show a warning dialog at all; (2) only show dialog on mobile; and (3) show dialog on both mobile and desktop. In the comment above by Saint Johann, it is noted that there would be only three lines of code needed to add a confirmation dialog on its own. Bundling it with history view makes things significantly more complicated. epicgenius (talk) 15:45, 23 April 2018 (UTC)[reply]
Confirmation is good. But, maybe having an inline 2nd confirmation (such as with the 'thank' feature), would be better than a pop-up? Rehman16:41, 23 April 2018 (UTC)[reply]
To me, the 'thank' feature is quite annoying, because you have to click a moving target. My opinion is that a large/modal confirmation would be better for the thank feature. //Shell17:40, 23 April 2018 (UTC)[reply]
The point of the rollback is to have really quick reverts, so a confirmation would create extra work. As a sysop on sv-wiktionary, I have never seen anyone use it by mistake, and I myself have only made the mistake a couple of times during over a decade as a sysop. In those cases it's easy to re-rollback and leave a comment. If this is implemented, I think that the default setting should be settable per wiki. //Shell17:40, 23 April 2018 (UTC)[reply]
Oppose and unsatisfactory to say "you can always go to Preferences and restore the behaviour you're used to", as many regular rollbackers will miss the memo and just click their teeth saying "they've changed something again and they're making me do more clicks". Noyster (talk) 18:51, 23 April 2018 (UTC)[reply]
Oppose. Many rollbacers uses it for quick action directly from watchlist or RC, when diff can be seen through pop-ups without opening. ANt these who wants to use safe rollback is possible to use gadget or userscript. JAn Dudík (talk) 18:58, 23 April 2018 (UTC)[reply]
Oppose as proposed. I would much prefer it to be an opt-in, rather than an opt-out, and I definitely want to keep the feature in lists. JTP(talk • contribs)19:05, 23 April 2018 (UTC)[reply]
Oppose as proposed. I recommend breaking these ideas down into separate options rather than lumping them together. First, leave the default as current, meaning that rollback is visible everywhere it currently is visible. If you have rollback rights, you know how to change settings, and should be involved enough to know the settings have been added. Second, split out the different lists. Where I personally want single-click rollback is on user contributions. I'd like to hide it on my watch list and on recent changes. If I don't hide it there, I might want to have a confirmation for those. But these don't need to be one-size fits all. Provide options. Let us choose rollback visible (single-click), rollback confirmed, or rollback hidden for each of the places rollback currently appears. It's a little more work to code the interface, but accommodates everyone's workflow. — The preceding unsigned comment was added by Dave Braunschweig (talk)
Oppose as an opt-out solution. There are existing solutions in many wikis (e.g. in pl.wiki as a user script) for people who want a pop-up confirmation of rollback action, so making this as an uniform gadget across many wikis would be a good idea, but only as an opt-in. Also, these two options (diff view/lists) in the proposal should be splitted into two different options in Preferences. Wostr (talk) 20:48, 23 April 2018 (UTC)[reply]
Oppose hiding any link. Consider a different solution: single click on rollback link -> a confirmation dialog opens; double click on a roolback link -> immediate rollback without confirmation dialog. --Alex brollo (talk) 21:42, 23 April 2018 (UTC)[reply]
Comment It would be a good idea if the user could decide whether or not to activate that option, otherwise, this can be a problem for those who frequently work with situations of vandalism that require acting quickly. —AlvaroMolina (✉ - ✔) 23:34, 23 April 2018 (UTC)[reply]
@AlvaroMolina: Thanks for your feedback! The proposed solution includes an (anti-)vandalism mode: Users can turn it on in their settings and get exactly the behavior as it right now, i.e. rollback links are shown in lists and there is no confirmation prompt. Please note that this is only a suggestion and that we are still in the research phase for this wish. -- Best, Johanna Strodt (WMDE) (talk) 08:50, 24 April 2018 (UTC)[reply]
Oppose per User:Saint_Johann. No need to make it more complicated. If someone makes this mistake often, they can be asked to add the code in their .js but forcing everyone to make extra clicks because of the sake of those few... is rather a step back then forward.Kind regards, Rodejong💬✉️23:39, 23 April 2018 (UTC)[reply]
Very Weak Support But I think it should only give the prompt when reverting multiple edits. Single edits should not have the confirmation. Also rollback was made to be able to revert quickly, not go through multiple steps. Bobherry (talk) 04:06, 24 April 2018 (UTC)[reply]
This is exactly backward. Keep the default as it is, and make the "confirmation" and "vanishing from lists" something that people can turn on in their preferences, who insist on using advanced privileges in contexts where they are incompetent to use them without causing problems. This is absolutely backward. Jytdog (talk) 05:10, 24 April 2018 (UTC)[reply]
Oppose If a person has rollback rights, they're a patroller, or wiki rights settings are not at the best. Adding an additional option is unnecessary. The common.css page is usable by the few people who don't want to have these links in their watching list. Regarding the watchlist page, why not use the same interface as the thanks extension? That is to say simply a confirmation page to load to confirm if no JS, and if javascript is present the link that changes to ask the user to confirm. --Framawiki (talk) 17:03, 24 April 2018 (UTC)[reply]
Oppose, Support the option. However, I agree with Jytdog that it should be the reverse default situation. I'm personally more likely to make a rollback error from misreading a diff. In any event, an accidental rollback can be reverted in moments, and the rollback diff screen should make it quite clear that a rollback has been performed. The option, of course, is useful, and on that front I agree with קיפודנחש's assessment that, should you have non-vandalism mode enabled, you should be able to leave an edit summary. Rollback is aimed at counteracting vandalism, and as such we should be focused on keeping it aimed at that purpose - fast reversion of clearly bad edits. Granted, it is useful for non-vandalism reversions, but support for that should not be the default. Another solution, which might please everybody, I've proposed below. Bellezzasolo (talk) 19:33, 24 April 2018 (UTC)[reply]
Oppose: Is a good idea to prevent any mis-clicks, but if this function used as default setting, it were be quite difficult for patrollers or rollbackers to fight vandals quickly, so I think this function use on preferences setting in manually were be preferable. SA 13 Bro (talk) 18:07, 25 April 2018 (UTC)[reply]
Oppose: I'm fine with making these options (or gadgets), but not as default. Note: If these become default, that should not be implemented until global settings are implemented.StevenJ81 (talk) 16:20, 26 April 2018 (UTC)[reply]
Oppose This is the wrong solution. The rollback function is primarily a very efficient anti-vandalism tool. It has to be convenient and fast in order to be meaningful. Even those users who tend to use it by mistake instead of clicking “thanks” shouldn't be hindered unnecessarily when they really need it. Why not simply rearrange the links, as has already been proposed, or probably add some graphical elements that could help make the distinction between the two functions better? This really is a UX problem that should be solved appropriately and not by crippling useful technical functions. — Luchesar • T/C07:35, 2 May 2018 (UTC)[reply]
Oppose the proposed solution. This will probably make the rollback a bit slower and a lot less effective, especially when the patrollers and/or the global rollbackers have to deal with multiple vandalisms. --Ted Masters (talk) 22:12, 4 May 2018 (UTC)[reply]
one of the weak points of "rollback" is the lack of summary. it seems to me 100% asinine to add "confirmation" form and not seize the opportunity to allow the rollbacker to add a summary. the summary should be absolutely "voluntary", meaning no summary should not trigger further "are-you-sure-prompts", but as long as we add confirmation form, not taking the opportunity to enable summary, is just silly. peace - קיפודנחש (talk) 15:02, 24 April 2018 (UTC)[reply]
@קיפודנחש: The rollback function can provide an edit summary; the user only needs to append «&summary=urlencoded_text» to a rollback URL. It, in turn, can be achieved with a script activating when a page is loaded and does not require any server-side modification beyond uploading personal scripts. I experimented with custom, filter-based edit summaries for rollback; a dialog box can be implemented as well, if warranted. Incnis Mrsi (talk) 16:17, 24 April 2018 (UTC)[reply]
i know all this, and a script i wrote years ago for hewiki for this purpose (confirmation+summary), achieve exactly this. the issue discussed here is creating a "confirm" form that will pop for every rollback, and what i wrote is that such a form will be an amazing waste if it won't provide the option to add a summary (and _not_ by "appending summary to the URL" - normal users do not interact with any "URL" when performing rollback). peace - קיפודנחש (talk) 17:29, 24 April 2018 (UTC)[reply]
I'm not sure I'd describe this as a weak point. Rollback is, on most Wikimedia wikis, to be used only for bad-faith edits, not for good-faith edits that didn't actually make the article better. The act of rolling back is supposed to be a sign in itself (usually construed as "this was vandalism"), which removes the need for a edit summary, not least because they take time to write. If one needs an edit summary, there's always the option of undoing. /Julle (talk) 17:05, 26 April 2018 (UTC)[reply]
@Julle:I routinely use rollback on good-faith edits after I informing a user of several poor edits by him/her. It is also the case—without deliberation at all—for edits which might be good-faith, but are obviously degrading, such as these. Incnis Mrsi (talk) 17:38, 26 April 2018 (UTC)[reply]
This means there is a buffer between plain rollback and thanking (fewer accidents!), the option to have a confirmation dialogue exists (also supporting the above summary idea), and vandalism can still be reverted quickly. Bellezzasolo (talk) 19:33, 24 April 2018 (UTC)[reply]
Until global options are implemented, hell no. I only have rollback on en.Wikipedia (as far as I know), and I have clicked rollback by mistake on mobile, but this solution would cause more damage than it protects against. If the default could be set only for new rollbackers, it wouldn't hurt as much, but it would triple the work for global rollbackers unless they could set global options. — Arthur RubinTC (en: U, T) 20:35, 28 April 2018 (UTC)[reply]
Support This is a great solution. Gryllida 06:26, 20 April 2018 (UTC)
Comment I do not support the proposed changes as new defaults.
Oppose any change and prefer the status quo. The background of this supposed problem is also incomplete. No statistical evidence of misclick is given, it is only asserted, and I disagree with that conclusion from the beginning. I have literally used rollback thousands of times and cannot remember mere 10 instances of misclick. This appears to be issue of one wiki and should be solved locally at that level without tempering with the global setup, which will impede the speed and easiness of fighting the determined vandals on the English Wikipedia. –Ammarpad (talk) 01:54, 22 April 2018 (UTC)
Strong oppose per MarcoAurelio, billinghurst and Framawiki. Hégésippe | ±Θ± 19:31, 24 April 2018 (UTC)