Wikipedia talk:Requested moves

Enter the title (or part of a title) to search for after "intitle:", then click "search"

Try other variants (e.g. "move discussion") to broaden or narrow your search

Twinkle now supports basic Requested move nominations

The latest Twinkle update has a new feature in the XfD menu allowing editors to nominate pages for RM; you can thank User:SD0001 for the stellar work! I'd imagine folks might want to wait to add it to the instructions on this page, but in the meantime do let me know if there are any issues I missed. ~ Amory (u • t • c) 18:01, 20 November 2019 (UTC)

Discussion at Template talk:RMassist#Show_redirects

 You are invited to join the discussion at Template talk:RMassist#Show_redirects. Ahecht (TALK
PAGE) 17:40, 3 December 2019 (UTC)Template:Z48

Close and dash?

Any thoughts on adding something to the closing instructions about closers having to remain available to address any questions and concerns about a close for some reasonable time after the close? I presume we all agree that closing an RM moments before a 6-month-long wikibreak is ill advised, but can we tighten that down some? Would it be reasonable to require checking for notifications on your talk page at least every day or two for a week or two after a close? And what about failure to respond to such questions/concerns? Can a close and dash be grounds for a revert without going through a Move Review? --В²C ☎ 22:22, 3 December 2019 (UTC)

No to all of that. There are certainly reasons to overturn a move closure, but the closer not answering questions is not among them. Parsecboy (talk) 22:32, 3 December 2019 (UTC)

Really? Athough closers don't have to be admins, closing discussions is arguably an "administrative" function, and I don't see why WP:ADMINACCT shouldn't apply to all RM closers: Administrators are accountable for their actions ..., as unexplained administrator actions can demoralize other editors ... Subject only to the bounds of civility, avoiding personal attacks, and reasonable good faith, editors are free to question or to criticize administrator actions. Administrators are expected to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions and to justify them when needed. Since this already applies to admins who close, shouldn't non-admin RM closers also be "expected to respond promptly and civilly to queries about their [closes] and to justify them when needed"? If so, then the question is, what to do when the closer does not meet these expectations? That's why I suggest a revert of the close is justified. I mean, if the closer is unwilling or unable to "respond promptly and civilly to queries about their [closes]", why not revert the close and let someone else close it? --В²C ☎ 01:20, 4 December 2019 (UTC)

It seems like a bad idea to condone reverting closures simply on the grounds that the closer hasn't responded quickly enough to satisfy a particular questioner. ╠╣uw [talk] 09:58, 4 December 2019 (UTC)

Is this a problem that comes up often? I don't feel like it's significant enough that it justifies the WP:CREEP cost of adding more rules. Also, the requirement to be responsive to messages within 24 or 48 hours seems excessive to me. Except for a few very rare cases (a controversial move of a high-profile page), there's no harm in waiting a few days for a response before going to MRV. WP:NODEADLINE and all that. Colin M (talk) 01:53, 4 December 2019 (UTC)

• Unilateral reverts of closed RMs? No. That sounds like the pre-MRV days when RM closes were insufficiently respected. Admins may revert (or counter sign) NACs (but not due to them being merely NACs) and otherwise challenges are entertained at MRV. WP:ADMINACCT-failures, including not being available to explain a close, if repeatedly done, should mean a WP:AN thread chastising the closer. —SmokeyJoe (talk) 12:39, 4 December 2019 (UTC)

  So if you inquire or complain about one of my closes on my talk page, I can just ignore it? Okay; good to know. --В²C ☎ 18:03, 4 December 2019 (UTC)

  If you did, my option is to escalate at MRV. Maybe my whinge was frivolous. However, if MRV sustained my challenge, I would seek to have you banned from closing discussions, not the first time though, but if it was becoming a pattern. ADMINACCT is important, and applies to non admins playing an admin role. However, unilateral reverts of closes is damaging to the process, and MRV exists as the forum to challenge closes. I note that I have found you to have always been very good at responding to inquiries or complaints about your closes. —SmokeyJoe (talk) 20:41, 4 December 2019 (UTC). I suggest that one week should be the expectation for responding to the inquiry or complaint. —SmokeyJoe (talk) 20:43, 4 December 2019 (UTC)

  But the first step in the MRV process, which is pretty heavy weight, is to contact the closer on their talk page. What is their incentive to address questions/concerns if the questioner's only recourse to a non-response is to start a bulky MRV? What's so bad about a justified-by-lack-of-response unilateral revert? It just means that somebody else - hopefully willing and able to respond to inquiries - will have to close it. Most RMs are cut and dried and will close the same way regardless of who closes. But for the gray area ones - the ones most likely to be questioned - those are the ones where closer availability and explanation is most important. Why go through an MRV simply because the closer was unwilling or unable to respond (since it's likely a response would eliminate the need for an MRV)? Why encourage closers to not respond? I get the resistance to unilateral reverts of RM closes, I certainly wouldn't want that, but it's easy to avoid in what I'm proposing: closers respond to inquiries about their closes. That's not unreasonable, is it? --В²C ☎ 21:00, 6 December 2019 (UTC)

  No one's encouraging closers not to be responsive. They should be, and in my experience they are. Your question was whether we need rules about it added to the closing instructions. Personally I don't think we do. ╠╣uw [talk] 22:26, 6 December 2019 (UTC)

  Okay. --В²C ☎ 23:05, 6 December 2019 (UTC)

Nothing is 'support' or 'oppose'

If there is no 'support' or 'oppose' the requested move proposal, how should I do? May I cancel it? -St3095 (talk) 07:12, 6 December 2019 (UTC)

If you created the proposal and no one has yet replied, you can delete it. If someone else has created the proposal, you should definitely not cancel it. Station1 (talk) 08:07, 6 December 2019 (UTC)

@Station1: So, will I delete the proposal, including level 2 header? -St3095 (talk) 08:54, 6 December 2019 (UTC)

I assume you're asking about Talk:Jung Yun-seok. I've deleted it for you. If that's not what you want, just revert my edit there. Station1 (talk) 16:52, 6 December 2019 (UTC)

@Station1: Thank you, Station1. You have already removing my requested move proposal. ←click this blue link to see what you last edited! -St3095 (talk) 01:12, 7 December 2019 (UTC)

Moving from sandbox

I have an old draft of an article in my sandbox that, at some point, I would like to move to main space. At the bottom of my sandbox, however, is material (a family tree) that is related to another article, and that predates the article draft I would like to eventually move. Is there a way to move the draft with its edit history, without the prior material? Or would the only way be to move all the material at once, and then delete the unrelated portion (which would then remain in the previous versions, accessible through "View history"). Thanks, --Usernameunique (talk) 17:55, 9 December 2019 (UTC)

Since you're the only person to edit your sandbox, I don't see any special reason to keep its edit history. I would just cut and paste the relevant source code directly into a new article in mainspace. That way the family tree will have never appeared in mainspace and will not have to be deleted. Station1 (talk) 22:37, 9 December 2019 (UTC)

Or,as a variation, rename your sandbox to, say, sandbox1, then copy/paste the latest edits (without the family tree stuff and anything else you don't want) into a new sandbox, and go from there. --В²C ☎ 23:51, 9 December 2019 (UTC)

Move Over Redirect

Hello, I am with the New Pages Patrol and often encounter new articles that are poorly titled. I frequently move such pages to correct titles because I have basic Page Mover authorization. But accordingly, I also frequently encounter situations in which a simple move is impossible because of an old redirect, then I must come here and make a request for a technical move. (And the folks here always get it done quickly.) I am wondering if I could do such move-over-redirect actions myself and if so, which permissions are required. If only Admins can do it, I have no need to take it that far and will simply bring requests here as before. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 20:45, 12 December 2019 (UTC)

The permission that allows for this is Wikipedia:Page mover. Iffy★Chat -- 20:49, 12 December 2019 (UTC)

I already have that permission, so I guess what I really need is practice on doing it. Next time the matter comes up, I will ask for more specific help. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 21:05, 12 December 2019 (UTC)

User:Andy M. Wang/pageswap allows you to make WP:ROBIN page swaps (which lets you swap a page and a redirect around) easily. Iffy★Chat -- 21:14, 12 December 2019 (UTC)

Locked

What is the point of locking this page for editing to autoconfirmed users if one of its intended uses is to allow unregistered and new users to request a move? "He opened a pub, but people kept visiting it," as we say in Czechia... --93.91.252.108 (talk) 21:27, 13 December 2019 (UTC)

You don't request potentially controversial moves on Wikipedia:Requested moves. Please make the move request on the talk page of the article you want to move.

You may make technical requests on the page Wikipedia:Requested moves/Technical requests, which currently isn't protected. – wbm1058 (talk) 21:56, 13 December 2019 (UTC)

New technical requests: Place at the top or bottom of the list?

The instructions for uncontroversial technical requests are in a hidden comment, and say:

• Insert the following code in the appropriate section, filling in page names and reason:
• {{subst:RMassist| current page title | new page title | reason = reason for move}}
• ---- and enter on a new line, directly below

That is, newer requests are placed at the top, like XfD. This is not particularly enforced, although seems to be mostly followed. As noted above, Twinkle now supports basic Requested move nominations, and follows those instructions at WP:RM/TR. Ammarpad requested a change to that behavior, asking Twinkle to place newer requests at the bottom, like RfPP or AIV. As such, I figured I'd open a section here to see if those instructions should change. ~ Amory (u • t • c) 16:12, 16 December 2019 (UTC)

Note that as well as the text "directly below" in the comment, the page's edit notice Template:Editnotices/Page/Wikipedia:Requested moves/Technical requests says "insert the following code at the top in the appropriate section" – wbm1058 (talk) 17:09, 16 December 2019 (UTC)

• The instructions are clear about placing newer requests at the top, and seem to be followed. I see no reason to change. --В²C ☎ 17:06, 16 December 2019 (UTC)

  Not necessarily, I've wandered about this myself and have done it sometimes at the top and sometimes after. "Directly below" could mean directly below existing comments or at the top). Crouch, Swale (talk) 18:41, 16 December 2019 (UTC)

  We could change "directly below" to "directly below this line" to avoid any ambiguity. Station1 (talk) 02:10, 17 December 2019 (UTC)

  Agree, WP:CFDS says "PLACE NEW NOMINATIONS AT THE TOP OF THIS LIST, BELOW THIS LINE". And its usually less difficult to work that out since items there tend to stay for 48 hours so show up in order while those at RMT are removed after being moved which is not normally more than a few hours. Crouch, Swale (talk) 08:12, 17 December 2019 (UTC)

  If anyone does change it, just let me know so I can update Twinkle! :D ~ Amory (u • t • c) 01:57, 22 December 2019 (UTC)

• I am the one who made the initial request, but after the initial objection I made it clear I don't want discuss this any further (because frankly I see the isssue not worth wasting time over) However I am commenting again since Amory mentioned me here. My reason of making the request (thinking it was just trivial) seems to be shaped with my workflow. Whenever I open the page I use to start from the topmost listing (which may have been placed just a minute before). If there are many entries for the day, the one at the bottom may spend several hours before being actioned, because of more and more newer requests that are being added. It also occurred to me at the time that the new behavior (listing at the top) started in few weeks/months back as before that most newer requests were placed at the bottom of existing requesting with very few exceptions, (I have not verified this with the page history, but I quite believe it's so). In addition, in many similar boards requests are placed at the bottom of existing request not top, to give few examples WP:RFP and WP:AIV. That was basically what prompted me to seek for the change. To repeat what I said, I don't think there's any benefit in discussing this further, I'd just adjust to the new style. – Ammarpad (talk) 23:28, 17 December 2019 (UTC)
• I have made this change, namely updating the comment to say directly below this line (emphasis added), as well as a further comment also recently added regarding newlines and accessibility (see conversation at WT:TW. Please let me know of any additional changes or tweaks so I can update Twinkle. ~ Amory (u • t • c) 11:57, 31 December 2019 (UTC)

When technical requests are contested...

When technical requests are contested... what usually happens is it gets converted into a regular RM. That sounds good but this is often problematic. First of all, when someone makes a technical request in good faith they assume there is no potential controversy and therefore don't fully explain the reasons for the move. So when it becomes an RM there usually is no strong argument. I find this problematic for two reasons. First, as someone looking at an RM request with weak or no argument I tend to oppose. Secondly, if I'm the person who made the initial technical move request, I don't want it converted to a regular RM request if it's contest. I want it rejected and for me to be notified. Then I could look at and consider the reason given for contesting/rejecting. That might tell me something I overlooked and that the move is not worth proposing - why waste any more time on this? But if I still think it should be moved then I can prepare a proper RM, that day, later in the week, or perhaps months later.

So what I'm proposing is that when technical requests are rejected due to being contested (whether you or someone else is contesting), just delete them and notify the person who made the request. Let them decide whether to even pursue it as a regular RM, and, if so, how to present it. --В²C ☎ 01:30, 17 December 2019 (UTC)

• How often does this happen? Every contested technical request should be taken as a TROUT. If you are making technical requests without serious consideration of possible reasons for contesting/rejecting, then you are not using sufficient consideration and should wind back on doing technical requests. That said, I think I agree that, by default, a rejected technical request should be flicked back at the nominator, not auto-made into a formal RM. I think it could/should be left to the discretion of an WP:RMTR#Contested technical requests admin-clerk. --SmokeyJoe (talk) 01:56, 17 December 2019 (UTC)
• This sounds reasonable to me. I've participated in a fair number of RMs that were born out of contested technical requests and they do tend to begin in a confused state for the reasons you mention. One little complication: an unscrupulous (or confused) editor who has a technical request bounced might just wait a while and then file it again. If they're lucky, no-one will notice, and it might succeed on the next try. Whereas if it got converted into an RM, that would create a permanent record of the previous request. I don't think this is likely to be a significant problem, but just playing devil's advocate. Colin M (talk) 02:08, 17 December 2019 (UTC)
• Born2cycle, see Template:RMassist#To opt out of discussion, if the request is contested. There have been requests in the past to make |discuss=no the default, and force editors to specify |discuss=yes if they want their contested requests automatically converted, but these proposals have been rejected. Search the archives. And I agree that every contested technical request from a highly experienced editor like you should be taken as a TROUT. – wbm1058 (talk) 05:31, 17 December 2019 (UTC)
  • Even if, for example, it's a technical request to revert a recent undiscussed move filed at Wikipedia:Requested_moves#Requests_to_revert_undiscussed_moves? --В²C ☎ 17:44, 17 December 2019 (UTC)
    • I'll assume you're referring to Cinema of Georgia. Yes, that one was a little awkward. Ideally the earlier discussion at Film industry in Georgia (U.S. state) would have been filed as a multimove discussion, but it's not unreasonable to take from Film industry in Georgia needing disambiguation that Cinema of Georgia would also need disambiguation. So the two admins here could have been less bold, but they weren't blatantly unreasonbly bold in their administrative decisions. It's not a good look to see you reverting two admins, even if technically you are procedurally correct. Show a little patience and let a discussion run for a week or two if necessary, even if the discussion is technically being hosted on the "wrong" title, it should be no big deal. I don't think there should be any "first-mover advantage" in cases like this, so it really shouldn't matter that much what title the article is sitting on during "discussion week". A little less reverting may lead to more feelings of good will. – wbm1058 (talk) 21:11, 17 December 2019 (UTC)
• If all contested requests are automatically removed that would just create another problem, inexperienced users may just continue listing the article, I have seen this already. I believe the current behavior is fine, experienced users should already know about |discuss=yes and use it to suppress the link if necessary. So no change is needed here. – Ammarpad (talk) 22:54, 17 December 2019 (UTC)

Confusing point in "potentially controversial"

In the section that appears as "Requesting controversial and potentially controversial moves", it has the following point:

• *there has been any past debate about the best title for the page;

I could interpret this either as:

• It's potentially controversial if there's been some notable debate in the past

-- or, possibly --

• It's potentially controversial if there's been no discussion.

If both interpretations are intended, shouldn't they be separate points?

Can we better clarify the distinction? --A D Monroe III^(talk) 19:29, 18 December 2019 (UTC)

• • It refers to the first interpretation... the move can be considered “controversial” if it has been debated before. Blueboar (talk) 20:08, 18 December 2019 (UTC)