Wikipedia talk:Page mover: Difference between revisions

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 7 sections are present.

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

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

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

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

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

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

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

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

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

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia policies and guidelines Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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]

Discussion

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

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

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

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

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

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

  Is there are particular reason why you (as an IP) are suggesting this addition? IPs are not given userrights, especially in your case, where you have a dynamic IP (you are .89, .72, .91, .70 today, etc). If you are editing while logged out, it might be of concern to others here. Added: no problem if you're generous and simply passionate about clearing backlogs :) — Andy W. (talk · ctb) 19:16, 17 May 2016 (UTC), 19:36, 17 May 2016 (UTC)[reply]

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]

Oppose: Include MergeHistory tool

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

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

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

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

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

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

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

7. Oppose This seems to be out of the scope of page movers. This makes history merging available to non-admins instead of what it is intended: admins. History merging is a pretty complicated process. --Pokéfan95 (talk) 06:29, 17 May 2016 (UTC)[reply]
   • History merging is a pretty complicated process: including what to do with the talk pages of the merged pages. Anthony Appleyard (talk) 09:06, 17 May 2016 (UTC)[reply]
8. Oppose. Merging histories is not affiliated with page moving. Anarchyte (work | talk) 11:37, 23 May 2016 (UTC)[reply]

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

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

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

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

Resolved

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

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^(TALK_CONT) 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^(TALK_CONT) 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]

• 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)[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^(TALK_CONT) 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 editor Godsy: 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, even if the moving editor were to request them 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  01:26, 27 May 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]

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

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

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

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

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

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

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

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

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

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

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia policies and guidelines Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

Support

1. Support. For move discussions that impact many pages, a higher limit is necessary. For instance, see Talk:2016_NFL_Draft#Requested_move_30_April_2016, which led to the move of over 60 pages. When large numbers of pages are to be moved, the most efficient way to do so is to get all of them to the move screen and tab through them submitting. When I implemented that RM, I ran into the throttle limit at least seven times, and I don't even do RMs much. For those who frequent the area, there absolutely is a need. ~ Rob^Talk 17:39, 26 May 2016 (UTC)[reply]
2. Support 20 per 60 30 per 60 I'm not even part of the group, and I think it's reasonable. The original RfC suggested 100, which was too much. I suggested 30 in that discussion. — Andy W. (talk · ctb) 17:45, 26 May 2016 (UTC)[reply]

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

3. Support Anything 20 and below seems reasonable. --QEDK (T ☕ C) 18:40, 26 May 2016 (UTC)[reply]
4. Support at 20 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]

Oppose

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]