Jump to content

Wikipedia talk:Page mover

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Coffee (talk | contribs) at 10:05, 26 June 2016 (→RfC: Increase throttle limit to 16 moves per minute: closing - request approved). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

RfC: Include the MergeHistory tool

Consensus among the participants of this RfC show that there is not support to add access to the history merge functions to the page mover group at this time. A discussion around the utility of granting access this function is taking place at the Village pump idea lab, those interested are encouraged to join there. — xaosflux Talk 23:14, 1 June 2016 (UTC)[reply]

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)[reply]

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)[reply]

I've restored the opposes, if anyone wishes to no longer oppose, they can remove it.—Godsy(TALKCONT) 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]

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(TALKCONT) 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). ~ RobTalk 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. --Pokéfan95 (talk) 06:29, 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]
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)[reply]

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(TALKCONT) 20:46, 25 May 2016 (UTC)[reply]
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)[reply]
Yes.—Godsy(TALKCONT) 03:59, 26 May 2016 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

@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(TALKCONT) 03:59, 26 May 2016 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
Thumbs up icon That is an improvement. —Godsy(TALKCONT) 03:29, 16 June 2016 (UTC)[reply]
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)[reply]
@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)[reply]

RfC: Increase throttle limit to 16 moves per minute

RATE LIMIT INCREASE APPROVED
With 25 in support and 8 opposed, the request to increase the move rate limit for extendedmovers is approved. (Note: A ticket has been submitted for this change to be patched to the software (T138703).) — Coffee // have a cup // beans // 10:04, 26 June 2016 (UTC)[reply]

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. ~ RobTalk 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 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. ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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 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)[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. ~ RobTalk 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 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)[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 [thɔ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. --Tom (LT) (talk) 06:36, 30 May 2016 (UTC)[reply]
  18. Support anything from 16 to 30 moves per minute. SSTflyer 10:20, 30 May 2016 (UTC)[reply]
  19. Support what looks like a sensible proposal. Enterprisey (talk!) (formerly 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: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)[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. --Pokéfan95 (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(TALKCONT) 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. ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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: 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)[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. ~ RobTalk 04:07, 15 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]
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)[reply]

@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]

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)[reply]

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

Xaosflux has posted a thread at Wikipedia_talk:Twinkle#Twinkle_enhanced_move_options, let's keep all related discussion there. (non-admin closure) Omni Flames (talk) 08:19, 14 June 2016 (UTC)[reply]

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)[reply]

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]
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.

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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(TALKCONT) 13:52, 14 June 2016 (UTC)[reply]
  • 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(TALKCONT) 14:36, 14 June 2016 (UTC)[reply]
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)[reply]
@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(TALKCONT) 16:07, 14 June 2016 (UTC)[reply]
I removed the second "the" because it sounded wrong. Omni Flames (talk) 22:22, 14 June 2016 (UTC)[reply]
Looks good to me. Omni Flames (talk) 22:22, 14 June 2016 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Page_mover&oldid=727057737"