Wikipedia talk:Page mover/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

What's the need?

Maybe there's a discussion I missed, but why exactly do we need a new userright for this? Oiyarbepsy (talk) 03:38, 4 May 2016 (UTC)

Read. --QEDK (T ☕ C) 09:40, 4 May 2016 (UTC)

@QEDK:FU. Read what? Oiyarbepsy (talk) 13:32, 4 May 2016 (UTC)

I'm quite sure there's at least 100 KB worth of arguments for the creation and usage of this permission above. I wonder why'd you skip all of it and make a thread asking for an explanation. --QEDK (T ☕ C) 10:10, 5 May 2016 (UTC)

• @QEDK:95% of the above discussion is about the details of how the permission would work. There are a handful of passing mentions of reasons - pretty much all mentions of page-move vandalism - but, as far as I can see, no one has said "We should do this because..." Either someone discussed this on another talk page, or some guy pulled this thing out of their ass. My oppose is guaranteed to remain until someone takes my question seriously. Oiyarbepsy (talk) 23:39, 5 May 2016 (UTC)
  • See the discussions about backlog etc. There was also some discussion of this during some recent RfAs if I recall. PaleAqua (talk) 00:14, 6 May 2016 (UTC)
    • It was originally discussed during Amakuru's poll at ORCP and a little at WT:Requests for adminship/Amakuru. But a lot of the discussion is up-page, above this RfC discussion. No one can deny that there are growing backlogs at WP:RM lately (well, everywhere, really, but RM has been one of the hardest hit...), so this is clearly needed. --IJBall (contribs • talk) 02:04, 6 May 2016 (UTC)

Revocation challenges

@MusikAnimal: Wikipedia:Page mover#Criteria for revocation's appeal method was modeled on WP:TPEREVOKE. Whichever way, it should be consistent. The only thing I found discussion wise with a quick glance at Wikipedia talk:Template editor was Wikipedia talk:Template editor#revocation. There are precedents for appealing on the permission request page, User:Alakzi for one.—Godsy^(TALK_CONT) 04:41, 25 April 2016 (UTC)

Thanks. You found a very good example, but it normally doesn't work out that way. PERM is patrolled by a small handful of admins. It's one thing to re-request the right once you feel you're ready for it again, but it isn't the best venue for something controversial like appealing another admin's decision. If someone does post at PERM for this purpose I certainly won't revert it, but from my time working there I've found stuff like this ultimately gets moved to AN or AN/I — MusikAnimal ^talk 04:58, 25 April 2016 (UTC)

Agreed, but ANI also garners too much unnecessary attention. I was the one who based it completely on TPE. Maybe something like RfRevocation? --QEDK (T ☕ C) 06:09, 25 April 2016 (UTC)

WP:AN would be the appropriate venue since this involves undoing another administrator's action, which should require consensus (with an obvious WP:IAR exception for any vandalism, but that's unlikely given the requirements to get this proposed right). ~ Rob^Talk 15:14, 16 May 2016 (UTC)

Question

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

This section has become outdated, assuming aspects of the user right not promoted to policy. I decided to courtesy close this section to avoid confusion. Discussion on move protection can be done in a new section. (non-admin closure) — Andy W. (talk · ctb) 22:59, 18 May 2016 (UTC)

---

Per discussion above, we're going to have page movers move move-protected pages. Does this mean they can move template-protected pages if they are not a template editor? Does it mean they can move fully-protected pages or files? If it were up to me, here's how I would go about moving restrictions:

1. No-move protection: any autoconfirmed user can move. 2. Move-protection: admins and page movers can move. 3. Template-protection: template editors and admins can move. 4. Files: file movers and admins can move. 5. Full-protection: only admins can move.

Thoughts? Peter Sam Fan 15:57, 13 May 2016 (UTC)

This discussion is broken across the page already in a few places, see #Discussion: Allow moving of move-protected pages and #Overriding sysop move protection. I advise against starting a third conversation about this topic. Ivanvector 🍁 (talk) 16:17, 13 May 2016 (UTC)

---

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

How about creating example no redirect here page?

Seems like there is confusion about exactly what a page will look like after the page under it has been moved away how about we create Wikipedia:Page mover/No redirect here and then move that to Wikipedia:Page mover/Move target without redirect with suppress redirect so that we have an easily referable example page? PaleAqua (talk) 03:55, 22 May 2016 (UTC)

I think this is a pretty good idea. APerson (talk!) 16:27, 22 May 2016 (UTC)

Group created - but missing option

The group has been created and can be assigned to users, however the interface is not yet supporting the redirect suppression feature. Subpage moves are now available, and the WP:PERM queue can be worked to start assignments. This is open as phab:T133981 still. — xaosflux ^Talk 18:23, 23 May 2016 (UTC)

The issue has been identified and is being worked on. — xaosflux ^Talk 18:35, 23 May 2016 (UTC)

Resolved

This is good to go now. — xaosflux ^Talk 18:54, 23 May 2016 (UTC)

Create topicon?

Can anyone create a Top icon for this user right (per {{Reviewer topicon}} and {{Top icon}})? Montanabw^(talk) 15:50, 26 May 2016 (UTC)

@Montanabw: It exists as {{Page mover topicon}}. — Andy W. (talk · ctb) 15:56, 26 May 2016 (UTC)

Great! Thanks! Montanabw^(talk) 16:08, 26 May 2016 (UTC)

OK, test run question

So, I picked a random article from the requested uncontroversial moves to try and use this new tool but am having trouble. , [1] -- I can only get the usual page move box and am stopped from proceeding further. I am missing some magic pixie dust here. Does this userright allow this? Looks like I have to move over a redirect, but I'm confused as to what to do. Montanabw^(talk) 17:32, 26 May 2016 (UTC) Follow up: I tried to follow the round robin discussion above, and got the article moved, but did I do it properly? Montanabw^(talk) 17:39, 26 May 2016 (UTC)

@Montanabw: I don't think it was clean. You left Draft:Rochester Rhinos Stadium and its talk page hanging. Being a page mover, you now have the option to use suppressredirect, which, during the round-robin move, you can suppress the redirect that happens when you move the page. I think the move you performed didn't use suppressredirect. — Andy W. (talk · ctb) 17:44, 26 May 2016 (UTC)

OK, I put csd tags on the pages I left hanging. Do I have the basic move itself completed now other than the leftover draft pages? But how do I do it right the next time so I don't have to do a csd? I think it's this way, but can you set me straight?

1. I see request to move A to B
2. B is a redirect and/or has some other minor content that does not allow a regular move and I get the
3. I move B to "DraftB" -- and I uncheck the box that says "leave redirect" to suppress it there??
4. Then I move A to B and DO leave a redirect
5. But then what happens to DraftB?
6. Also, how do I get the talk page to move?

Or do I somehow have it all backwards?? Montanabw^(talk) 17:53, 26 May 2016 (UTC)

@Montanabw: I think you're okay. Definitely go check the double-redirects and fix any you see.

About page-swapping: Suppose you see a request to move "A" to "B", and you deem it uncontroversial and would like to proceed. Suppose both pages have non-trivial page history. This means that the pages need to be swapped. To do this:

1. Move "A" to a new page "C" (with suppressredirect, you should be able to do this now with page mover)
2. Move "B" to "A" (with suppressredirect)
3. Move "C" to "B" (with suppressredirect)

This way, you don't have to tag anything left over with CSDs. — Andy W. (talk · ctb) 17:57, 26 May 2016 (UTC)

I don't know what the check boxes look like, but I think you're right. Don't leave a redirect at any point in the process. — Andy W. (talk · ctb) 17:58, 26 May 2016 (UTC)

@Montanabw: To move the talk page with it, make a move on the article page, not the talk page. There should be a button that says "Move associated talk page". — Andy W. (talk · ctb) 18:07, 26 May 2016 (UTC)

OK, so I think I just skipped a step. Will look for another noncontroversial technical request and try it again.... Montanabw^(talk) 23:10, 27 May 2016 (UTC)

Discussion at VPI

I've started a discussion here regarding the creation of a new "history merger" user right, which may be of interest to those watching this page. Omni Flames ^{let's talk about it} 07:09, 31 May 2016 (UTC)

Edit request to this page

Criteria number 5 for moving pages without redirect is Moving a file per WP:FNC#9 (WP:CSD#G6) (the file mover user right is also required to move files). That limits the total number of non-admin combined page/file mover users significantly (as of this writing: from 24 page movers to 8 combined page/file mover users). I suggest adding a note, such as (For filemovers only) Moving a file per WP:FNC#9 (WP:CSD#G6), to clarify that regular page movers can't move a file without leaving a redirect. Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 23:10, 28 May 2016 (UTC)

I don't think I have a conflict of interest, so I made an edit in line with what's been suggested. If anyone would like to revise how it's stated, please do so! — Andy W. (talk · ctb) 04:03, 30 May 2016 (UTC)

@Andy M. Wang: Thank you for adding the requested edit, though I didn't really intend it to be a COI request; it was more like a general request. Anyway, I like the phrasing of your edit – it's better than my proposal. Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 12:43, 31 May 2016 (UTC)

RfC: Include the MergeHistory tool

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I suggest that the mergehistory right also be included. It provides access to Special:MergeHistory through which history merges can be performed.

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)

Support	Oppose	Total	% support
4	11	15	26.67

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)

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)

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)

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

• Please see WP:HM#Using the MergeHistory special page. Consider the recent merge of List of Irish-Americans and Americans of Irish descent (edit | talk | history | links | watch | logs) into 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)

  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)

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

  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)

Support: Include MergeHistory tool

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

   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)

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

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

   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)

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)

   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)

   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)

2. Oppose for many reasons including the ones given above below.—Godsy^(TALK_CONT) 14:06, 16 May 2016 (UTC)
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)
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)

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

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

   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)

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. --Pokéfan95 (talk) 06:29, 17 May 2016 (UTC)
   • 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)
8. Oppose. Merging histories is not affiliated with page moving. Anarchyte (work | talk) 11:37, 23 May 2016 (UTC)
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)
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)
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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Adding warning for page moves to certain targets

Tracked in Phabricator
Task T85393

A phabricator request has been opened to request warnings for certain types of moves (e.g. to blacklist, to protected titles, etc). If you are interested in this, please see phab:T85393. — xaosflux ^Talk 01:53, 29 May 2016 (UTC)

@Xaosflux: If page movers cannot override the title blacklist, what is the point of warning page movers when attempting to? — Music1201 ^talk 8:56 pm, Today (UTC−5)

@Music1201: This isn't about page movers per se, just in general. Currently admins don't get warned on this either. And someone who is say a template editor and a page mover (that can override the black list) also doesn't get warned. — xaosflux ^Talk 02:01, 29 May 2016 (UTC)

And as far as protected titles go, a page can be create protected with a low level of protection (like semi-); as for previously deleted - it may be worth looking at the log before doing the move. Note, all this is just to provide more information to the editor wanting to make a move, nothing is preventative. — xaosflux ^Talk 02:03, 29 May 2016 (UTC)

@Xaosflux: I think this is a good idea, but wouldn't the warning have to be dynamic? (E.g., if someone theoretically tried to rename a page to "Something Epic Fail", it should give an error message, like the red box you get when you try to input <>{}[] as part of the page title, because "Epic Fail" is on the title blacklist. But if the person changed that input to "Something Epic Win", it should not give an error message.) Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 02:10, 29 May 2016 (UTC)

Yes, we would be looking for it to be dynamic, basically evaluating a few new conditions such as:

1. IF (move target) was previously deleted : Identify this was previously deleted AND show last deletion log entry
2. IF (move target) collides with the title blacklist : Identify this is on the black list AND show expression hit(s)
3. IF (move target) has a create protection level : Identify this has a protection level AND show last protection log entry

Similar logic is already in place on the "CREATE PAGE" mechanic. — xaosflux ^Talk 02:15, 29 May 2016 (UTC)

Is there a warning if an admin tries to move a file, and the target file name exists on Commons? These moves require reupload-shared, which is currently admin-only. --Stefan2 (talk) 14:05, 2 June 2016 (UTC)

@Stefan2: Yes the error is: MediaWiki:Move-over-sharedrepo and they have to hit move a second time. — xaosflux ^Talk 14:13, 2 June 2016 (UTC)

Page mover closure

This was not mentioned here before, but for general awareness by page movers, see Wikipedia:Requested moves/Closing instructions#Page mover closure. — Andy W. (talk · ctb) 06:01, 5 June 2016 (UTC)

RfC: Increase throttle limit to 16 moves per minute

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

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)

Table

Support	Oppose	Total	% support
25	8	33	75.76

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)

   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)

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)

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

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

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

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

6. Support would also support higher. PaleAqua (talk) 21:01, 26 May 2016 (UTC)
7. Support. To editor Rob: I see above that this is sort of a test to see how high the limit might be that would receive support, and I'd be interested to know what limit would have been best for you in the example you gave at Talk:2016 NFL Draft#Requested move 30 April 2016? That would probably be the limit I'd support.  OUR Wikipedia (not "mine")! Paine  03:56, 27 May 2016 (UTC)

   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)

   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)

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)
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 WP:RM often contains move requests where a large number of pages need to be moved due to a new systematic title scheme being applied to existing pages. These are backlogged presumably due to the time-consuming process of moving these pages if there is a consensus to move. The whole point of this permission was to help with the permanent backlog at WP:RM, so why would we not provide them with all the tools necessary to do so, particularly if uncontroversial requests like 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)
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)
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)
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)
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)
14. Support 20/30 per discussions above. Anarchyte (work | talk) 09:13, 29 May 2016 (UTC)
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)
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)
17. Support for an increase in productivity with a very small overall risk to the community. --Tom (LT) (talk) 06:36, 30 May 2016 (UTC)
18. Support anything from 16 to 30 moves per minute. SSTflyer 10:20, 30 May 2016 (UTC)
19. Support what looks like a sensible proposal. Enterprisey (talk!) _{(formerly APerson)} 19:06, 30 May 2016 (UTC)
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)
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)
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)
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)
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)
25. Support per BU Rob13. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:54, 20 June 2016 (UTC)

Oppose

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

   The OP has. SSTflyer 03:00, 29 May 2016 (UTC)

2. Oppose per Nakon and my comment below. — Music1201 ^talk 01:51, 29 May 2016 (UTC)
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)

   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:JR-type stuff) page move requests at WP:RM/TR (in fact, there's just such a list there right now!) where I could see someone doing that just to get through them quickly to clear them off WP:RM/TR – it's in those kinds of situations where it could be possible to go over the 8/60 moves limit. I think if we trust an editor with WP:PMVR, we can trust them with a 20/60 throttle limit... --IJBall (contribs • talk) 04:18, 31 May 2016 (UTC)

   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)

4. Oppose A lower throttle means much easier to watch pagemoves. --Pokéfan95 (talk) 03:16, 30 May 2016 (UTC)
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)

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

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

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)

• 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)
  • See support #1 for my explanation of how I've run into the throttle limit. ~ Rob^Talk 01:54, 27 May 2016 (UTC)
    • @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)
      • @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)
• 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)
• 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)
  • Why can't Cydebot do those moves? Jenks24 (talk) 19:52, 30 May 2016 (UTC)
    • @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)
      • 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)
    • 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)
      • 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)
• Comment. Unaware as to how many of us have read this; however, I thought it might be helpful here: Wikipedia:Don't worry about performance. Some appear to be concerned about what a higher throttle may lead to. It's true that an infinite limit such as that had by admins means that a malicious admin could have a huge adverse effect on the servers in this and so many other ways. As page movers we also should be careful even at a lower throttle. Hope the essay helps to ease some minds!  OUR Wikipedia (not "mine")! Paine  11:13, 31 May 2016 (UTC)
  • 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)
• 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)

  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)

  • 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)
    • @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)
• 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)
  • 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Give page movers the ability to overwrite pages with a non-trivial page history through moves

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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 WP:PM/C#4 are tedious and it's pretty easy to mess things up. The vast majority of technical requests and RMs I handle generally require such an action. It would be so much easier and faster if I had the ability to simply move the page to a title which has history larger than just a redirect. It's already technically possible for page movers to achieve the same effect by using suppressredirect so I don't see why giving them this right would be a problem. Omni Flames (talk) 10:42, 13 June 2016 (UTC)

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)

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)

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

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

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

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

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What's the "best" way to do 3-point "round-robin" moves?

So, I think it might be good if we could come up with a "standard" method for carrying out so-called "3-point 'round-robin' moves" (i.e. A → C (temp), B → A, C (temp) → B), because right now there isn't one. I just used a "[title] (temp)" disambiguator to carry out a round-robin move. It looks like Godsy carried it out with "[title]/holding" sub-directory temp. Someone else suggested using Draftspace for the temp page (maybe that's the best way to go?...). But this is probably worth having a discussion about. Pinging – @QEDK, Xaosflux, Coffee, and Anthony Appleyard:, for starters... --IJBall (contribs • talk) 20:32, 25 May 2016 (UTC)

It would be good to establish a standard way of doing it overall. I personally prefer and execute the moves as B → C (temp), A → B, C (temp) → A. A → B, the goal of the move, shows a bit clearer that way in the logs. (temp), /holding, or some other format; I don't really have a preference yet (let's see what is proposed).—Godsy^(TALK_CONT) 20:46, 25 May 2016 (UTC)

Well, I guess the "lettering" depends on whether A=Redirect/B=Article, or A=Article/B=Redirect – in my version, A=Redirect; I suspect in yours, B=Redirect. --IJBall (contribs • talk) 22:31, 25 May 2016 (UTC)

Yes.—Godsy^(TALK_CONT) 03:59, 26 May 2016 (UTC)

So let's be really really clear about what you want to accomplish, start with defining:

(a) An example of pages that exist

(b) What you ultimately want it to look like when you are done

— xaosflux ^Talk 21:31, 25 May 2016 (UTC)

And yes, there could be multiple use cases - list each one as a scenario and we can help document it. — xaosflux ^Talk 21:45, 25 May 2016 (UTC)

Generally, most examples are going to be like the one I did today (and I guess that Godsy did yesterday(?)): moving an article to the location of a redirect-with-a-non-trivial-revision history. (I can't think of any other instances where the 3-point "round-robin" move would be necessary – are there other scenarios?...) In my case, the redirect was at the desired destination: "Kenneth L. Farmer Jr.". So I did (all with suppressredirect): Kenneth L. Farmer Jr. [the redirect] → Kenneth L. Farmer Jr. (temp), Kenneth L. Farmer, Jr. [the article] → Kenneth L. Farmer Jr., Kenneth L. Farmer Jr. (temp) → Kenneth L. Farmer, Jr. [the new location for the redirect where the article formerly was].
What I'm really asking is – what should we use for the "temp" location: "[title] (temp)", "[title]/holding", or "Draft:[title]", or something else, when attempting these 3-point moves? --IJBall (contribs • talk) 22:44, 25 May 2016 (UTC)

• I want to say a subpage - but that could have unintended consequence if a "page" being moved already has subpages. To avoid patroller issues etc, staying out of article space may also be helpful - lets get some more feedback. I'm thinking some sort of page like Draft:Pagemove/Kenneth L. Farmer Jr. would be a good idea... — xaosflux ^Talk 23:41, 25 May 2016 (UTC)

@Xaosflux and IJBall: While keeping these temporary pages out of the mainspace avoids confusion for those watching a new page patrol listing, it adds another layer of complication and more work for the mover, as the namespace selector has to be moved twice. The moves are technical enough already.—Godsy^(TALK_CONT) 03:59, 26 May 2016 (UTC)

I understand your point, and I haven't tried it xaosflux's way yet, but if it works I do think going through Draftspace is the best way to go. We probably can't/shouldn't "require" Page movers to go through Draftspace, but if it works out it should definitely be suggested as an option for 'round-robin' moves. --IJBall (contribs • talk) 04:26, 26 May 2016 (UTC)

Agree, this shouldn't be "required" - but in building a set of directions it can be recommended. — xaosflux ^Talk 10:30, 26 May 2016 (UTC)

To editors Godsy and Xaosflux: Before I apply for this user right, I'd like to be clear on the new page patrol issue. Apparently, any editor can accomplish a "back door" round robin. One just moves the more-than-one-edit redirect (B) to a new page (C temp), then (theoretically) one moves the incorrectly-named page (A) to the correctly-named first redirect (that now only contains one edit), then moves the newly created page to the incorrectly-named page. Since none of the redirects that result from these page moves are suppressed, I can see where this might be a new page patrol concern (since C temp is still hangin' around), even if the moving editor were to request C temp to be speedily deleted. With suppressredirect, all those redirects (left behind) are squelched, so the newly created page is gone when a page mover (with right) has completed the moves. Is the concern here that the newly created page that ultimately gets suppressed/deleted hangs around on the page patrol list like a ghost? or doesn't it immediately disappear from the list after being suppressed/deleted?  OUR Wikipedia (not "mine")! Paine  04:55, 27 May 2016 (UTC)

I think that "move over redirect" only allows you to move C back to B but that you can't move A to B. I think that you need either "suppressredirect" or "delete" in order to do what you suggest. --Stefan2 (talk) 22:09, 1 June 2016 (UTC)

@IJBall and Godsy: Wikipedia:Moving a page#Swapping two pages ? — Andy W. (talk · ctb) 23:58, 25 May 2016 (UTC)

The "improved sequence" there (that should maybe retitled to something else, like "Round-robin sequence") is what we're talking about, but it doesn't tell you how/what to put at "C".
It would be good if we could come up with a standard "C" – I actually like xaosflux's Draft:Pagemove/Kenneth L. Farmer Jr. suggestion though it's maybe a little "wordy": Draft:Move/Kenneth L. Farmer Jr. or Draft:Temp/Kenneth L. Farmer Jr. might be simpler... --IJBall (contribs • talk) 00:03, 26 May 2016 (UTC)

Subpages of Draft:Move may work in general (again you may run in to a problem if moving a page with sub-pages). — xaosflux ^Talk 00:35, 26 May 2016 (UTC)

• A -> A (temp); B -> A; A (temp) -> B. Simplest imo. --QEDK (T ☕ C) 18:38, 26 May 2016 (UTC)

Just follow the directions at WP:SWAP because a round-rubin move is actually a history swap. 24.205.8.104 (talk) 05:09, 27 May 2016 (UTC)

Again, WP:SWAP doesn't tell you where to put "C", which is what this discussion is trying to establish. It seems that there is some consensus to use "Draft:Move/[article redirect]" as "C", which seems like a good way of handling this to me. --IJBall (contribs • talk) 13:30, 27 May 2016 (UTC)

It really doesn't matter, you could just button mash random letters if you want (indeed I've seen people do that). I'd be against recommending a change in namespace if only because the move interface makes it irritating. Jenks24 (talk) 19:58, 30 May 2016 (UTC)

• Why does it matter what the temporary page is called? If you want to swap the page titles A and B, then you must perform the move via some temporary page title C, but the page will only be at C for a few seconds or so, so I fail to see why it matters how the page title C is chosen.

How do these moves affect new page patrollers? Do patroller tools show page moves? --Stefan2 (talk) 22:09, 1 June 2016 (UTC)

Arbitrary break

@Paine Ellsworth and Godsy: I know you were involved in writing a good section of how the round-robin move works. I made a bold update to the round-robin section. It's probably slightly less prosaic, but I think gets the point across a bit more clearly. Please feel free to refactor it as appropriate. — Andy W. (talk · ctb) 03:03, 16 June 2016 (UTC)

Thank you, Andy! I'm down with your improvements, so keep it up!  What's in your palette? Paine  03:18, 16 June 2016 (UTC)

 That is an improvement. —Godsy^(TALK_CONT) 03:29, 16 June 2016 (UTC)

Question what happens with subpages moves when moving to from a subpage at a different level? Should the instructions that give the Draft:Move/XYZ example note the concern with subpages. If I understand how things work I can see a case that subpages get left behind and potentially moved to a different page. Would it be a good idea to check Special:PrefixIndex/Draft:Move/ and Special:PrefixIndex/Draft talk:Move/ to check for lost subpages? PaleAqua (talk) 06:52, 16 June 2016 (UTC)

@PaleAqua: I did some tests in my userspace involving a page and its subpages being moved to a non-existing subpage, and it works fine. If I try to move the "main" page to one of its existing subpages, it does not work. Ideally, the round-robin move is as "atomic" as possible so that stray subpages being moved elsewhere doesn't happen. (The PrefixIndex links could be a helpful link.) — Andy W. (talk · ctb) 15:36, 16 June 2016 (UTC)

• Sometines people ask for "swop pages A and B", where A is a redirect to B, and he merely needs a plain move A to B, and remove the redirect at B, and leave a redirect at A. Anthony Appleyard (talk) 16:23, 11 July 2016 (UTC)
  • Yeah, it's sometimes the case that a page is at a typo name, "A-Typo", with a redirect from the correct name "B-Correct", and moving A-Typo to B-Correct over the redir, without leaving a redir behind, is the desired ultimate outcome (after any links to A-Typo are fixed), because the A-Typo redir created by a normal move is something that would be deleted at RfD. Doesn't come up every day, of course. Another such case is when one finds a really awkward WP:DESCRIPTDIS that fails WP:CONCISE and other criteria; if the original, bletcherous name is not a likely search phrase, there's no need for a redir to remain from that title (e.g. "List of academics in chemistry that have got one of the Otto Hahn Prizes" or whatever).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:36, 11 July 2016 (UTC)

Does suppressing a redirect when draftfying after an AFD fall under the criteria for suppressing a redirect listed at WP:PM/C#3?

Quick question. I've seen a number of AFDs which I could probably close as "moved to draft". It would be useful to be able to use suppressredirect when doing so, however I'm not sure if this falls under the criteria for suppressing a redirect listed here. It would be a little pointless to leave a CSD tag on the redirect when I could've just never created it in the first place. So, my question is, would suppressing a redirect as part of acting on the outcome of an AFD or similar discussion fall under WP:PM/C#3? The criteria states that it can be used for pages in the wrong namespace. I suppose that one could argue that if an AFD has been closed as move to draft then the article is technically in the incorrect namespace. Omni Flames (talk) 08:25, 14 June 2016 (UTC)

Found a precedence. See the log/history for Draft:Rafay Baloch (Rafay Baloch). 2 examples of moves to Draft citing WP:R2: Geta (slang) and Beast of Burden (film). Godsy, who wrote a good chunk of that part, may have further comments. — Andy W. (talk · ctb) 08:42, 14 June 2016 (UTC)

I'd advise leaving a note on the author's talk page telling the author where their page has gone. New editors, the sort prone to creating ill-considered new articles, are also likely to be unaware of their watchlist and contributions page, and will just assume the page has been deleted, and re-create it otherwise. for (;;) (talk) 09:07, 14 June 2016 (UTC)

@Andy: Thanks for the examples. Of course, the scenario I'm asking about is a little different as the pages actually have community consensus to move them to draft space.

@For (;;): I'm not sure how necessary this is as when a page is deleted or moved with suppressredirect the latest entries in the deletion and/or move log come up if you click on the red link, so the page creator would probably see that it had been moved. Omni Flames (talk) 09:42, 14 June 2016 (UTC)

Omni Flames, I wish I could point you at the example I have in mind. It was a page that cropped up in WP:NPP two days running. The title was an obvious typo. An admin moved it on first occurrence without leaving a redirect. On second occurrence the same admin converted the typo article to a redir.

There are many new users who come to the wiki with the fixed idea of creating their article. I suspect that when they click on the redlink, they just see that they're now on a paged titled "Creating <your article>", skip over the deletion notice, and blindly recreate the article they thought they'd created the day before.

Just my 2¢. Feel free to ignore it. for (;;) (talk) 10:39, 14 June 2016 (UTC)

@Omni Flames: It doesn't fall under WP:PM/C#3, but WP:CSD#R2 does apply. As long as a the title that would become a redirect would meet a criteria for speedy deletion, it is okay to suppress it.—Godsy^(TALK_CONT) 13:52, 14 June 2016 (UTC)

• A possible sixth criteria for redirect suppression:

No.	Criteria	Shortcut
6	Moving a page from the mainspace to another namespace when appropriate (WP:CSD#R2)	WP:PM/C#6

—Godsy^(TALK_CONT) 14:36, 14 June 2016 (UTC)

added "after AfD consensus" (???), because as it was currently phrased, it could be mis-interpreted that any mainspace page could be PM/C#6'd. — Andy W. (talk · ctb) 15:30, 14 June 2016 (UTC)

@Andy M. Wang: Changed it to "when appropriate". It isn't exclusive to AfD consensus, no need to explicitly limit it to that as there are other valid uses, though that will probably be the case the majority of the time this is used. It could be used per consensus from another XfD venue or per the request of the creator of a page (the latter if recent, and WP:PM/C#3 would apply it as well). Once in a blue moon I'll userfy a page that would otherwise be deleted when a new user creates a page and explicitly marks it as "under construction" etc. (e.g. User:Garethmsedge/Impero education pro).—Godsy^(TALK_CONT) 16:07, 14 June 2016 (UTC)

I removed the second "the" because it sounded wrong. Omni Flames (talk) 22:22, 14 June 2016 (UTC)

Looks good to me. Omni Flames (talk) 22:22, 14 June 2016 (UTC)

I see I'm a bit late, but Godsy, I don't think it needs to be recent. WP:CSD#G7 doesn't stipulate a time frame, and that's outright deletion instead of a move. —Compassionate727 ^(T·C) 16:49, 11 July 2016 (UTC)

@Compassionate727: You're correct, as long as the "the only substantial content of the page was added by its author". If others have expanded upon it, it isn't eligible. Best Regards,—Godsy^(TALK_CONT) 23:26, 11 July 2016 (UTC)

• Added it, as it is already supported by the criteria for speedy deletion policy. If anyone objects, they are welcome to revert it, and we can proceed to more formally seek community input and consensus.—Godsy^(TALK_CONT) 03:48, 15 June 2016 (UTC)
  • Thanks for that. Omni Flames (talk) 07:10, 15 June 2016 (UTC)
• A possible seventh criteria for redirect suppression:

No.	Criteria	Shortcut
7	Moving a page to the userspace or other applicable namespace per a request by the original author when the only substantial content was added by them (WP:CSD#G7)	WP:PM/C#7

@Omni Flames, Andy M. Wang, For (;;), and Compassionate727: Thoughts? —Godsy^(TALK_CONT) 23:54, 11 July 2016 (UTC)

For #7, I would say a specific request by the author is required. I wouldn't consider a request to move an article automatically a request to suppress the redirect. Possibly reword as "Author request to move a page without a redirect when the only substantial content was added by them (WP:CSD#G7)"? ~ Rob₁₃^Talk 00:00, 12 July 2016 (UTC)

@BU Rob13: From the mainspace to any other namespace it would be implicitly (WP:R2), but I suppose those cases are already covered by WP:PM/C#6.—Godsy^(TALK_CONT) 00:45, 12 July 2016 (UTC)

@Godsy: Looks all right to me if this covers another good set of cases, probably does. Though I'd say that at a certain point, the remaining cases would be either commons sense, WP:BOLD, or just not done. Recently, I did a slew of moves on editnotices with redir suppress to avoid the editnotice showing up on the former page (since an editnotice that redirects to a different one will pick up the contents of that one and show it, which is almost always undesriable. It didn't really fit criteria, but was G6 is most cases) — Andy W. (talk · ctb) 00:10, 12 July 2016 (UTC)

(edit conflict) @Godsy: Wouldn't that fall under #6 anyway? Omni Flames (talk) 00:11, 12 July 2016 (UTC)

@Omni Flames: The difference appears to be that #6 is for mainspace-only, while #7 is for pages in general (including Templates or Portals, potentially) per user request, which appears to be the opposite of #2. Godsy, I'm thinking now that expanding #2 to include userspace→new location AND new location→userspace might be more concise, possibly even avoiding WP:CREEP a bit. — Andy W. (talk · ctb) 00:18, 12 July 2016 (UTC)

Ah, okay, thanks for clarifying. Omni Flames (talk) 00:38, 12 July 2016 (UTC)

I can't speak for others, but I'm specifically thinking of things like Draftspace to Mainspace (common for drafts), Userspace to project space (common for proposals/RfCs), or Userspace to Draftspace (common for WP:AFC submissions). They're all relatively uncontroversial, and with a specific author request, I see no reason to leave a redirect. ~ Rob₁₃^Talk 00:54, 12 July 2016 (UTC)

(edit conflict) @Andy M. Wang: Your point coupled with BU Rob13's point (i.e. that obscure cases don't need to be documented and that a move request of the nature specified isn't a request for deletion unless stated explicitly, except in the case of mainspace to x namespace) make a reasonable case to leave it out. One could simply link to WP:G7 should this situation arise and the author requests deletion (as stated in the guideline "Page movers can suppress a redirect during a page move if the redirect would be eligible for one of the criteria for speedy deletion.").—Godsy^(TALK_CONT) 01:03, 12 July 2016 (UTC)

Arbitrary break pmc2

• @Andy M. Wang: Broadening criteria 2 to cover what 7 would could be done in this way:

No.	Criteria	Shortcut
2	Moving pages within a requester's own userspace to another location or from any namespace to another per a request by the author when the only substantial content was added by them if a desire for deletion is expressed or you are the author (WP:CSD#U1/WP:CSD#G7)	WP:PM/C#2

—Godsy^(TALK_CONT) 02:07, 12 July 2016 (UTC)

@Godsy: If the wording includes "any to userspace", "userspace to any", and "any to any", maybe it makes sense to collapse it to say "Moving pages upon user request (includes userfication and draft publishing) along with desired redirect deletion (WP:CSD#U1/WP:CSD#G7)". — Andy W. (talk · ctb) 04:37, 12 July 2016 (UTC)

Guidelines for granting: Number of page moves

I recently noticed this user right was granted to a user who only had two entries in their move log (one action as it was a page and its respective talk page). While that's what lead me to post here, that's not what I'm here to discuss (I've already had a more private word with the administrator who granted the request). I'm here to propose that we add some guidance concerning this to the guidelines, something along the lines of: At a bare minimum those requesting should have 20 entries in their move log. This will assure they've performed at least 10 page moves, and are somewhat familiar with the ability in general. The wording I've suggested is purposely strong. I don't think users who are unfamiliar with the basics of moving pages should be given the extended toolset, rather we ought to refer them to WP:RM/TR, if they are in need of the services this user right would provide.—Godsy^(TALK_CONT) 00:40, 31 July 2016 (UTC)

I disagree, because I think that will encourage admins to grant this to any requesting editor with 20 pages moves. This is one of those user rights like template editor or file mover where an editor should demonstrate a need for the right, not just make a few moves where the right wouldn't change anything. I thought that was clear from past discussions, but I guess not, so I'd certainly support adding strong wording to this effect. ~ Rob₁₃^Talk 02:52, 31 July 2016 (UTC)

Meeting any guideline will "encourage admins to grant [the right] to any requesting editor", so that argument applies to any guideline. However, I understand your point to a certain extent, as this right has an affinity to page moves because it extends abilities related to them.—Godsy^(TALK_CONT) 05:39, 31 July 2016 (UTC)

By that logic Rob, we should also remove the 3000 edits or more guideline, because they encourage admins to grant this to any requesting editor with 3000 edits. Same goes for the 6 months guideline. Omni Flames (talk) 05:43, 31 July 2016 (UTC)

@Godsy: Neutral about a hard-set limit. I think the current wording should already signal to admins that 1-2 moves is not sufficient to gauge understanding of titling guidelines. I'd support something like The editor should have demonstrated experience with moving pages in accordance with titling guidelines. — Andy W. (talk · ctb) 20:44, 3 August 2016 (UTC)

Page move vandalism to delete redirect?

Interested in feedback for a scenario that involves a "legitimate" use of page move vandalism to delete a bad (G3/R3) redirect:

• User 1 moves A → B with a bad title.
• User 2 moves B → A. (Bad title B is a redirect left behind, and User 2 does not nominate B for CSD)

PM notices B. PM could probably G3 the redirect B, but if B has 1 revision and points to A, the following is technically possible:

• Move A → B ("vandalism")
• Move B → A with suppressredirect (which "deletes" B)

The first procedural action can be hard to explain and may confuse other editors. Does WP:PM/C#1 cover the scenario? Or should the mover simply tag B to avoid two extra revisions in the page's history? (I ask this now because I found this when answering a move request.) — Andy W. (talk · ctb) 17:04, 11 August 2016 (UTC)

Actually I retract any notion of adding to PM/C#1 per WP:CREEP, but thought this was interesting to note — Andy W. (talk · ctb) 15:05, 12 August 2016 (UTC)

• Either "moved page A to B over redirect" and then "moved page B to A over a redirect without leaving a redirect", or "moved page A to B over a redirect without leaving a redirect" and then "moved page B to A without leaving a redirect". It does not matter whether you suppress the redirect or not when moving A to B, but you must suppress it when moving B to A. This would allow non-admins to delete a redirect with just one edit in the history, by simply moving the target over the redirect and then back, where redirect suppression does not matter for the first move but it does for the second move. GeoffreyT2000 (talk) 17:35, 18 August 2016 (UTC)

Round-robin script

Hi, for folks interested, I've written a script that semi-automates round-robin page swaps. See User:Andy M. Wang/pageswap. I've been using the form provided by JS that allows simply to enter the title of the destination, which saves a lot of time having to manually go through the move form 3 times.

If find any issues, report it to me. Feedback is welcome, and if anyone wants to point out code inefficiencies (I'm not much of a JS scripter), let me know as well. Feel free to adapt this script as you see fit. — Andy W. (talk · ctb) 18:22, 24 August 2016 (UTC)