Wikipedia talk:Page mover

I suggest that the mergehistory right also be included. It provides access to

Unlike manual history merges by admins (which involve a sequence of moves, deletions and undeletions), merges done using MergeHistory are easy to revert. It can only be used for merging histories that run non-parallely and log entries exactly indicate the timestamp of the latest merged-in edit, making merge acrions easily revertible. MergeHistory can only be used for performing simple history merges. Many (which typically require the deletion of a few redirect edits) woud still require admin intervention.

Why this is needed? There is a huge backlog at WP:WikiProject History Merge that has remained nearly dormant for years. There is also a smaller backlog at Category:Possible cut-and-paste moves. These backlogs could benefit from increased attention.

103.6.159.89 (talk) 08:48, 16 May 2016 (UTC)[reply]

Discussion

@Andy M. Wang, Mcmatter, and Godsy: I have moved the section out of the Rfc, because of the reasons you've already stated. And renamed this section as it consists purely of opposes based on its late introduction into the rfc. If you still wish to oppose, please add it in the section above. 103.6.159.89 (talk) 14:14, 16 May 2016 (UTC)[reply]

I've restored the opposes, if anyone wishes to no longer oppose, they can remove it.—Godsy^(TALK_CONT) 15:04, 16 May 2016 (UTC)[reply]

I changed my vote to abstain for now. It might make sense to bundle mergehistory with page mover (or, as I believe it's called extendedmover now) to help the backlog. But just a general comment. Around 2008/9, I was aware that we promoted many new folks to adminship at a good rate. Was it an issue back then? In 2015, when I wasn't paying much attention, I expected there to be around 2500 to 3000 admins by now. We might have a shortage of admins, dare I suggest it. (despite the tool-unbundling initiative).

Also want to add that if mergehistory is bundled with page mover, than something like unwatchedpages warrants bundling with Rollbacker. — Andy W. (talk · ctb) 18:57, 16 May 2016 (UTC)[reply]

(Changing my mind a bit much on this page) Despite my support of the tool-unbundling initiative, I suspect that there are also qualified folks who are not going for adminship, who might be magnanimous enough to look into these backlogs. — Andy W. (talk · ctb) 20:00, 16 May 2016 (UTC)[reply]

• Please see
  List of Irish-Americans and Americans of Irish descent (edit | talk | history | links | watch | logs). You can examine the histories of both the pages. You'll see that there's not a tad of junk anywhere. Histmerge junk that needs to reverted occurs only with one particular method of manual histmerge (used by Anthony Appleyard). Special:Mergehistory also doesn't cause deletion of any revisions. It's somewhat similar to supressredirect as it just moves revisions from one page to another, the only difference being that we are talking about moving revisions to a page that already exists. You can test it out on the The Test Wiki. @BU Rob13 and Compassionate727: You're free to oppose but confusing up facts doesn't help anyone. 103.6.159.70 (talk) 07:44, 17 May 2016 (UTC)[reply
  ]

  Is there are particular reason why you (as an IP) are suggesting this addition? IPs are not given userrights, especially in your case, where you have a dynamic IP (you are .89, .72, .91, .70 today, etc). If you are

  editing while logged out, it might be of concern to others here. Added: no problem if you're generous and simply passionate about clearing backlogs :) — Andy W. (talk · ctb) 19:16, 17 May 2016 (UTC), 19:36, 17 May 2016 (UTC)[reply

  ]

• Recommend quickly archiving this - the last comment prior to this one was at 17:29, 26 May 2016 (UTC). Unless there is further discussion, I recommend archiving this RfC 7 days after that comment, at 17:29, 2 Jun 2016 (UTC) on the grounds that the current RfC was made moot by the parent proposal becoming policy without this RfC either passing or failing. I further recommend that 3-6 months from now a new RfC be started on the topic Disclaimer: I have little use for the current page-move user-right, but I could make heavy use of a userright like mergehistory. davidwr/(talk)/(contribs) 23:26, 28 May 2016 (UTC)[reply]

  Sounds fine to me. I turned this into an RfC after the initial IP split this section off from the original. I mean, at this point, this doesn't look close to being passed. Might be able to summarily close this. — Andy W. (talk · ctb) 03:58, 30 May 2016 (UTC)[reply]

Support: Include MergeHistory tool

1. Support as proposer. 103.6.159.89 (talk) 08:48, 16 May 2016 (UTC)[reply]
2. Support MergeHistory is constantly backlogged; the current backlog is probably in excess of 300 pages. --Bigpoliticsfan (talk) 12:23, 16 May 2016 (UTC)[reply]

   Actually, it's not just over 300 pages.

   WP:WPHM has thousands and thousands of pages. 103.6.159.91 (talk) 18:28, 16 May 2016 (UTC)[reply

   ]

   Support. This would help a lot with the backlog. –Compassionate727 ^(T·C) 13:38, 16 May 2016 (UTC)[reply]

3. Support per Bigpoliticsfan. Users who can be trusted to have extended rights with moving pages can be trusted to perform history merges. If anyone disagrees with that, why not create a "History merger" user group. It is a pretty well needed group considering the 1000+ backlog. — Music1201 ^talk 00:26, 26 May 2016 (UTC)[reply]
4. Support: It's part of the package and often needed, particularly for merges of long-established content forks into a new, unified article. Montanabw^(talk) 17:29, 26 May 2016 (UTC)[reply]

   This gives me cause for concern. You are the type of trustworthy experienced editor who I would expect should be granted the page mover right, but content merges are exactly what the histmerge tool should not be used for. Jenks24 (talk) 19:55, 30 May 2016 (UTC)[reply]

Oppose: Include MergeHistory tool

1. Oppose,
   RfC creep. Let's save this for a later discussion.Abstain for now reinstating my vote. Not necessary for the group. — Andy W. (talk · ctb) 18:23, 16 May 2016 (UTC)[reply
   ]

   Adding a right to an aleady existing group is unlikely to achieve consensus. Plus, it would be a major change and thus require another full-on RFC. It would be most productive that we discuss this now itself. @Andy M. Wang: You're free to oppose but it would be appreciated if you would !vote on the basis of merits of the proposal rather than on superficialities. 103.6.159.89 (talk) 12:16, 16 May 2016 (UTC)[reply]

   Oppose- This is a great idea, but to be introduced so late into this RFC process is out of order and should handled as a separate RFC. Many people have already voiced their concerns, may not be watching this any more and would not see another userright being added in which they may support or oppose. McMatter ^(talk)/_(contrib) 13:01, 16 May 2016 (UTC) Removing my oppose for now McMatter ^(talk)/_(contrib) 18:26, 16 May 2016 (UTC) [reply]

2. Oppose for many reasons including the ones given above below.—Godsy^(TALK_CONT) 14:06, 16 May 2016 (UTC)[reply]
3. Oppose as this was introduced late, and there has been no discussion in this almost-month-long RfC about why a user tasked with moving pages has any need to merge histories. They seem to be to be entirely separate functions. Ivanvector 🍁 (talk) 15:08, 16 May 2016 (UTC)[reply]
4. Oppose. I would probably weakly oppose such a user right since history merges are akin to deleting a page (unless deletion as a whole was spun off, but that's probably a step too far). ~ Rob^Talk 15:23, 16 May 2016 (UTC)[reply]

   FYI, Special:MergeHistory does not cause deletion of any edits. 103.6.159.91 (talk) 18:28, 16 May 2016 (UTC)[reply]

5. Oppose. A histmerge is a lot more complicated than simply moving a page, and the histmerges that I've seen result in junk that needs to be cleaned up afterwards. Frankly, I think this is pretty complicated and should just be left for the admins. Indeed, the fact that it is so complicated is probably why there's a several-thousand page backlog. –Compassionate727 ^(T·C) 18:42, 16 May 2016 (UTC)[reply]
6. Procedural oppose – opposing not on the merits, but on the timing (this RfC is scheduled to close in three days, and shouldn't be kept open later just for this "late add" proposal). However, once Page mover rights are set up, as with moveoverredirect, adding mergehistory to the package can be mulled over and discussed at a later date... Let's get this package set up first, and see how it goes, before start trying to "add on" to it. --IJBall (contribs • talk) 02:08, 17 May 2016 (UTC)[reply]

   The IP moved this section out of the RfC to this new section, intending separate discussion now, I think. Perhaps we can use this opportunity to discuss moveoverredirect and mergehistory, and the rights not part of the patch. — Andy W. (talk · ctb) 02:49, 17 May 2016 (UTC)[reply]

7. Oppose This seems to be out of the scope of page movers. This makes history merging available to non-admins instead of what it is intended: admins. History merging is a pretty complicated process. --
   talk) 06:29, 17 May 2016 (UTC)[reply
   ]
   • History merging is a pretty complicated process: including what to do with the talk pages of the merged pages. Anthony Appleyard (talk) 09:06, 17 May 2016 (UTC)[reply]
8. Oppose. Merging histories is not affiliated with page moving. Anarchyte (work | talk) 11:37, 23 May 2016 (UTC)[reply]
9. Oppose - the main task a page mover has to be able to handle is to decide the correct title for a given page; this ability has nothing to do with this task, as the page is already in the correct place. עוד מישהו Od Mishehu 14:45, 30 May 2016 (UTC)[reply]
10. Oppose If a user is given the right to perform some action, then the user should also be given the right to reverse the action. In order to reverse a history merge, the user needs the delete and undelete tools and lots of patience. Also, the purpose of the page mover user right is to allow some users to perform slightly more complex moves. History merging is a different and more complex task (delete, move, undelete). --
    Stefan2 (talk) 21:58, 1 June 2016 (UTC)[reply
    ]
11. The mergehistory tool is generally quite useless. More often, it randomly fuses some parts of both histories, and requires a good ol' delete and move to fix it up after. Also really unsure what merging history has to do with moving pages; seems like creep to me. Ajraddatz (talk) 22:13, 1 June 2016 (UTC)[reply]

Should those with page mover rights have an increased throttle limit of 16 moves per minute, compared to the 8 moves per minute throttle that they currently have? This RfC is in response to this past discussion, where there was no support for an increase to 100 moves per minute, but wider support for a smaller increase. ~ Rob^Talk 17:39, 26 May 2016 (UTC)[reply]

Tech details

• This is an update to InitialiseSettings.php
• This will add a new rate limit for moving pages:

   '+enwiki' => [ // Tnnnnnn n=phab ticket
      'extendedmover' => [ 16, 60 ], //16 moves per 60 seconds (subject to different values below)
   ],

— xaosflux ^Talk 01:00, 30 May 2016 (UTC)[reply]

Table

Support

1. Support. For move discussions that impact many pages, a higher limit is necessary. For instance, see
   Talk:2016_NFL_Draft#Requested_move_30_April_2016, which led to the move of over 60 pages. When large numbers of pages are to be moved, the most efficient way to do so is to get all of them to the move screen and tab through them submitting. When I implemented that RM, I ran into the throttle limit at least seven times, and I don't even do RMs much. For those who frequent the area, there absolutely is a need. ~ Rob^Talk 17:39, 26 May 2016 (UTC)[reply
   ]

   I originally suggested 16/60 because it's double the current number, but every support has been geared toward 20/60, and I'm fine with that too. ~ Rob^Talk 21:52, 28 May 2016 (UTC)[reply]

2. Support 20 per 60 30 per 60 I'm not even part of the group, and I think it's reasonable. The original RfC suggested 100, which was too much. I suggested 30 in that discussion. — Andy W. (talk · ctb) 17:45, 26 May 2016 (UTC)[reply]

   @Andy M. Wang: I think 20 or 30 could get support, but I put this intentionally low so that we at least get some increase to help with the majority of instances. Of course, if people support an even larger increase, great. I'd support anything up to 30, I think. I struggle to think of any use case that would require larger than 30 because it takes at least two seconds to just hit the submit button. ~ Rob^Talk 17:47, 26 May 2016 (UTC)[reply]

3. Support Anything 20 and below seems reasonable. --QEDK (T ☕ C) 18:40, 26 May 2016 (UTC)[reply]
4. Support at 20up to 30 mpm. — xaosflux ^Talk 19:13, 26 May 2016 (UTC)[reply]
5. Support up to whatever sysops are allowed. Ivanvector 🍁 (talk) 20:29, 26 May 2016 (UTC)[reply]

   @Ivanvector: - sysop is set to unlimited. — xaosflux ^Talk 22:26, 26 May 2016 (UTC)[reply]

   'kay. Ivanvector 🍁 (talk) 23:41, 26 May 2016 (UTC)[reply]

6. Support would also support higher. PaleAqua (talk) 21:01, 26 May 2016 (UTC)[reply]
7. Support. To editor
   OUR Wikipedia (not "mine")! Paine  03:56, 27 May 2016 (UTC)[reply
   ]

   This isn't so much a test as an attempt to get an inch, even if a mile is preferable. If consensus emerges for an increase to 20 or 30, that would be great for the non-admins at RM, but I'd rather make a marginal improvement than the no improvement that resulted from the previous discussion. Based on how I conducted the moves (getting all pages to the move screen with reason typed in then rapidly hitting submit), a limit of 30 would have been useful. Given the current throttle, I worked in batches of 8 instead, but I often hit the throttle just because it doesn't take 60 seconds to give the move screen a once-over and hit submit. A throttle of 15-20 would be a substantial improvement, as I could then work in batches of 10 or so without worrying about the throttle. ~ Rob^Talk 04:11, 27 May 2016 (UTC)[reply]

   Thank you, Rob! Judging by what you've said, and considering that administrators have an unlimited throttle, it would appear that 30/60 or even 40/60 would be supportable. I would support a throttle limit of 40 for editors with the page mover user right.  

   OUR Wikipedia (not "mine")! Paine  04:18, 27 May 2016 (UTC)[reply

   ]

8. Support – I prefer 20/60, but I see no problem with either 20/60 or 16/60. If users can be trusted with Page mover, they can be trusted with a moderately higher throttle limit. --IJBall (contribs • talk) 13:33, 27 May 2016 (UTC)[reply]
9. Support – A limit on how many moves can be performed within a certain time span seems pretty illogical for a usergroup called page mover. The backlog at
   this one succeed? I would support an increase to unlimited, but since there was opposition in the original RfC, any increase would be beneficial in my view. Eventhorizon51 ^(talk) 03:22, 28 May 2016 (UTC)[reply
   ]
10. Conditional support: It appears this throttle is completely arbitrary and serves no purpose beyond assuming that accidents or ill intent may happen, and to protect against it. If this is not the case, and there's a good reason to have a throttle, then my !vote may swing. Otherwise, I'd support removing the throttle completely along the lines of giving 'em enough rope and letting the chips fall where they may; if page movers can't be trusted to move any number of pages, then they shouldn't be page movers at all. Fred Gandt · talk · contribs 06:37, 28 May 2016 (UTC)[reply]
11. Support anything up to 20/60. I'm neutral towards 30/60 and opposed to anything above that. Wugapodes [t^hɔk] [kantʃɻɪbz] 17:59, 28 May 2016 (UTC)[reply]
12. Limited support to 20/60 or something, to allow a move of up to 20 subpages per minute. This should be used very sparingly, though. Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 23:06, 28 May 2016 (UTC)[reply]
13. Support with the understanding that page movers take full responsibility for each and every move. I don't as a general rule think that doing anything fast is particularly advisable.However, since page mover is (hopefully) only going to people with common sense, I don't see the point in trying to use inflexible software limitations to enforce it. Also, RM is a conscensus driven area so there will hopefully be plenty of people able to detect any worrisome carelessness very quickly. Happy Squirrel (talk) 02:12, 29 May 2016 (UTC)[reply]
14. Support 20/30 per discussions above. Anarchyte (work | talk) 09:13, 29 May 2016 (UTC)[reply]
15. Support, a need has been dempnstrated, and an increase to up to 30 moves per minute seems perfectly reasonable. 20 seems to be the number gaining consensus, and would solve a lot of these problems. Tazerdadog (talk) 10:06, 29 May 2016 (UTC)[reply]
16. Support: This is meager increase that will greatly aid real-person productivity, while not particularly enabling any quasi-automated train wrecks, or terrible "going postal" behavior.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:36, 30 May 2016 (UTC)[reply]
17. Support for an increase in productivity with a very small overall risk to the community. --
    talk) 06:36, 30 May 2016 (UTC)[reply
    ]
18. Support anything from 16 to 30 moves per minute.
    flyer 10:20, 30 May 2016 (UTC)[reply
    ]
19. Support what looks like a sensible proposal.
    APerson) 19:06, 30 May 2016 (UTC)[reply
    ]
20. Support I personally think an even higher throttle limit would be appropriate, but I suppose this is a start. Omni Flames ^{let's talk about it} 06:50, 31 May 2016 (UTC)[reply]
21. Support Reasonable. (I'd also support 20 or 30 ppm and limiting admins to whatever pagemovers get as a limit. Only bots have genuine reason for having no rate limit.)—Ruud 09:14, 31 May 2016 (UTC)[reply]
22. Support - This is a reasonable step up. There's no indication that it would be likely to cause serious problems.- MrX 18:59, 1 June 2016 (UTC)[reply]
23. Support - this will allow page movers to do their task better when multiple moves are necessary. עוד מישהו Od Mishehu 11:54, 2 June 2016 (UTC)[reply]
24. Support - Why not? Sixteen should be a suitable number to increase. I see a potential issue about allowing undesirable moves in one minutes. Nevertheless, 16 ain't that huge of a number. George Ho (talk) 06:08, 16 June 2016 (UTC)[reply]
25. Support per BU Rob13. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:54, 20 June 2016 (UTC)[reply]

Oppose

1. Oppose, has this limit been hit by the page movers? Nakon 06:15, 28 May 2016 (UTC)[reply]

   The OP has.

   SSTflyer 03:00, 29 May 2016 (UTC)[reply

   ]

2. Oppose per Nakon and my comment below. — Music1201 ^talk 01:51, 29 May 2016 (UTC)[reply]
3. Oppose Loss of quality control/issues of someone going rogue with this. 16 page moves per minute is one every 2.66 seconds. Not exactly a massive time-lag between each move. Lugnuts ^{Dick Laurent is dead} 08:17, 29 May 2016 (UTC)[reply]

   The idea is for people who stack up several open web browser tabs to move several pages in (quick) sequence. I'm not saying I do that (I think most PM's don't), but a few do and I trust they know what they're doing. I've already seen times where there are lists of 5–10 simple (e.g.

   WP:PMVR, we can trust them with a 20/60 throttle limit... --IJBall (contribs • talk) 04:18, 31 May 2016 (UTC)[reply

   ]

   I've seen admins with a lot of experience screw things up at RMTR by doing just that. There is no legitimate reason to do more that 8 separate moves in a minute and it is one of my biggest frustrations that people who are granted advanced userrights use them to try and button mash their way to a high score. If anything, the admin throttle should be significantly lowered. Jenks24 (talk) 06:39, 7 June 2016 (UTC)[reply]

4. Oppose A lower throttle means much easier to watch pagemoves. --
   talk) 03:16, 30 May 2016 (UTC)[reply
   ]
5. Considered supporting, but I don't think the example given by the OP is a good one. More care needs to be taken with each move. Jenks24 (talk) 19:05, 30 May 2016 (UTC)[reply]

   Oppose I don't see a reason to let anyone go off on a fast pagemove rampage on their own initiative. If more than a few dozen pages are involved, there should be prior discussion similar to a BRFA. If such a discussion takes place and a plan is approved, then an admin can temporarily lift the limit on a specific editor, or have them use an alternate account that would temporarily get a bot flag to do the moves. 50.0.121.79 (talk) 05:24, 4 June 2016 (UTC) (IPs have no voting power on permissions discussions. - Indented — Coffee // have a cup // beans // 09:50, 26 June 2016 (UTC))[reply]

6. Oppose Community oversight will become unfeasible if we keep granting God-mode privileges to power users. Considering all the ponderous rules and wikitricks that govern – and throttle – a user's efforts to bring a single page move to adjudication, I say an 8/60 limit is already generous. SteveStrummer (talk) 06:09, 6 June 2016 (UTC)[reply]
7. Oppose - A need for an increase has not been adequately demonstrated. The cases where this would be useful are far and few between, and as such, the potential for abuse or mistakes outweighs the benefit. An admin or bot can reasonably be expected to handle said cases in situations where simply waiting out the timer when the limit is hit (which, to reiterate, is uncommon) is not feasible. Care needs to be taken with each page move (as Jenks24 stated), so a low limit is a net positive.—Godsy^(TALK_CONT) 06:13, 6 June 2016 (UTC)[reply]
8. Oppose. I can't see any possible reason for one to be making a move every four seconds. If anybody exceeds eight per minute, the quality of such moves would have to be absolutely reprehensible. –Compassionate727 ^(T·C) 22:17, 7 June 2016 (UTC)[reply]

Discussion

While I support the increase, those with the userright should be aware that getting even close to 8/60 may be problematic. It's been impossible for me to even hit 1/60. I think a move is not complete until all new resulting double redirects are corrected, and without automation or semiautomation, so a move takes minutes for me. — Andy W. (talk · ctb) 18:33, 26 May 2016 (UTC)[reply]

• Question Why would this be needed? It's very unlikely that a user would need to move more than 8 pages in 60 seconds, in fact, it may not even be possible to complete 8 page moves in that time. As per the comment above, this may not be needed. — Music1201 ^talk 21:35, 26 May 2016 (UTC)[reply]
  • See support #1 for my explanation of how I've run into the throttle limit. ~ Rob^Talk 01:54, 27 May 2016 (UTC)[reply]
    • @Andy M. Wang: In a situation where there is 60 page moves, a throttle limit increase to 16 won't help. I say either increase to a larger number like 60 or not at all, there just seems to be no use for it. — Music1201 ^talk 03:45, 27 May 2016 (UTC)[reply]
      • @Music1201: It takes some time to do a once-over on the move page (making sure you have the reason in properly, etc). For me, I took around two seconds on the once over. While that would indicate a throttle limit of 30 needed to prevent hitting the throttle entirely while doing mass-moves in my preferred manner, you could at least do my method in batches of 10 without hitting the throttle with a limit in the 15-20 range. As it stands, I hit the throttle even when working in batches of 8 on that move. It takes less than a full minute to get eight pages to the move screen with identical reasons. ~ Rob^Talk 04:14, 27 May 2016 (UTC)[reply]
• As a side note, ping me if you want any response from me here on out. I've made several comments because I ran into a relevant use case that demonstrates need, but I don't want to bludgeon the discussion either, so I'm going to avoid making further comments unless specifically asked to. Cheers. ~ Rob^Talk 04:16, 27 May 2016 (UTC)[reply]
• Found a new use case; I've been working on the backlog at
  WP:CFD, and when you're working through a category tree that was nominated as a whole, there are huge numbers of moves involved. If we intend page movers to be able to work on renaming closes at CfD, this is desirable. ~ Rob^Talk 19:16, 30 May 2016 (UTC)[reply
  ]
  • Why can't Cydebot do those moves? Jenks24 (talk) 19:52, 30 May 2016 (UTC)[reply]
    • @Jenks24: Non-admins can't list categories for Cydebot at Wikipedia:Categories for discussion/Working. We can either do them ourselves or nag the few admins who regularly participate at CfD to list them after we close the discussions, which would get old very quickly. To head off the anticipated "then don't close those discussions" response, the backlog at CfD goes back to February and includes many discussions that the admins who frequent CfD can't close due to their own participation in the discussions. Short of "get more admins at CfD" (easier said than done), non-admins closures of these sorts of discussions seem necessary. ~ Rob^Talk 05:07, 31 May 2016 (UTC)[reply]
      • It seems silly to effectively force non-admin closers into so much more work because they can't edit a certain page. There must be a simpler solution. I can't see what's wrong with leaving the list on the talk page and letting an admin copy/paste it across – seems like a mountain less work. Even creating another protection level so that experienced NACs such as yourself can edit that page seems like a simpler alternative in the long run. Jenks24 (talk) 11:51, 31 May 2016 (UTC)[reply]
    • As we have seen many times, being reliant on a single editor (or their bot) to run parts of the project can be very disruptive when they break down or turn off; "someone else could do this" isn't a very strong argument. — xaosflux ^Talk 00:35, 2 June 2016 (UTC)[reply]
      • Surely it is just common sense to use a bot for these mass category moves, it's what admins do to. And regarding the reliance on one bot, Cydebot has been going for over a decade now and there is a failsafe in ArmbrustBot. I really cannot see how it's productive for anyone to be doing these moves manually. As an aside, if anything this discussion has convinced me the rate should be lowered for admins rather than increased for page movers. Jenks24 (talk) 15:25, 3 June 2016 (UTC)[reply]
• Comment. Unaware as to how many of us have read this; however, I thought it might be helpful here:
  OUR Wikipedia (not "mine")! Paine  11:13, 31 May 2016 (UTC)[reply
  ]
  • I'm not worried about server performance- I'm worried about disruption and annoyance to humans editing the wiki. 50.0.121.79 (talk) 05:45, 4 June 2016 (UTC)[reply]
• Comment. I've noticed editors who moved a page to a (much more reasonable) new name without checking redirects to the old page. On at least 1 occasion, a new page mover used suppressredirect and neglected to check for double redirects. I've made corrections as I found them... I don't know if bots can make the fixes if the redirect is not there. Members of the group should definitely be familiar with Wikipedia:Moving a page#Post-move cleanup, especially when using suppressredirect. There are certainly cases where cleanup is minimal after moving 60 pages in about 5 minutes, but prior to the action, investigation into DISPLAYTITLEs and redirects should be a given. Can the rate limit be different depending on whether suppressredirect is used? — Andy W. (talk · ctb) 20:09, 8 June 2016 (UTC) 20:26, 8 June 2016 (UTC)[reply]

  It 'could' be done - but would be a much bigger technical change then updating the one line for "move" actions. (The request would then need to be for software changes and parameter changes). `— xaosflux ^Talk 23:33, 8 June 2016 (UTC)[reply]

  • If page movers aren't checking for double redirects, that's a problem. I would consider that within the criteria for revocation under number 2 if the editor is asked to adjust their process and fails to do so. ~ Rob^Talk 04:07, 15 June 2016 (UTC)[reply]
    • @Andy M. Wang: It seems like a good idea at first, but there are some situations where all this would do is hinder suppressredirect moves. For example, reverting mass page move vandalism. Omni Flames (talk) 07:12, 16 June 2016 (UTC)[reply]
• RfC expired. I posted at ANRFC for an admin to close this and potentially open a phabricator ticket. — Andy W. (talk · ctb) 18:18, 25 June 2016 (UTC)[reply]
  • Pinging as-of-now-uninvolved Coffee, who closed the previous RfC and suggested this follow-up had high potential. — Andy W. (talk · ctb) 18:25, 25 June 2016 (UTC)[reply]

Is it possible that we could give page movers the ability to move articles to a title that has a history that would normally disallow anyone but admins from moving to it? As a page mover, I can say that "round-robin" page moves covered under

Such a move is not a merge, but a delete - so are you suggesting this group be able to delete any page? — xaosflux ^Talk 11:32, 13 June 2016 (UTC)[reply]

Agreed. That deletes revisions. At least with the those moves, the revisions stay alive, so they can be reverted back if necessary. —Compassionate727 ^(T·C) 22:25, 13 June 2016 (UTC)[reply]

@Omni Flames: Is the scenario moving page "A" to its redirect "B" that happens to have more than 1 revision? I know that admins delete the redirect to make way for the move. Page movers do round-robin and need to fix the redirect at the end of the procedure because "B", now at "A", is still pointing at "A" when it should point to article at "B". I think page movers should stick to using suppressredirect, for which they have earned trust both technically and for pagenaming.

One thing Omni Flames might be indirectly suggesting is what I call swappages, a flag bundled with extendedmover and sysop, which allows specifying two pages, and the two pages' contents/histories(/deleted revisions?) are swapped. Perhaps the form is at Special:SwapPages or something. — Andy W. (talk · ctb) 22:52, 13 June 2016 (UTC)[reply]

@Xaosflux: Ah okay, I didn't realize it required a deletion.

@Andy M. Wang: Yes that's the scenario I'm referring to. Round-robin page moves work fine and I've already performed a large number of them. However, the main problem is that when there are a large number of pages that require moving this way, or when I'm processing technical requests, round-robin page moves take a long time to perform.

Something like swappages would certainly be nice. Of course, we'd need an RFC to get consensus for it. Omni Flames (talk) 22:58, 13 June 2016 (UTC)[reply]

"Swapping" two pages (round robin style) is something someone can probably make a twinkle like script for - input page 1, 2, press go... just saying...— xaosflux ^Talk 00:02, 14 June 2016 (UTC)[reply]

Wikipedia_talk:Twinkle#Twinkle_enhanced_move_options posted. — xaosflux ^Talk 00:14, 14 June 2016 (UTC)[reply]