Misplaced Pages

:Requested moves/Closing instructions: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages:Requested moves Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 20:04, 20 February 2015 editRed Slash (talk | contribs)Autopatrolled, Extended confirmed users, Page movers, Pending changes reviewers, Rollbackers21,804 edits okay, I think I like this. It sums up what we do pretty clearly... thoughts?← Previous edit Latest revision as of 14:57, 6 December 2024 edit undoBobby Cohn (talk | contribs)Extended confirmed users, Page movers, New page reviewers, Pending changes reviewers, Rollbackers28,682 edits →Determining consensus: adding shortcut WP:RMNCREV 
(358 intermediate revisions by 100 users not shown)
Line 1: Line 1:
{{Explanatory supplement|interprets=Misplaced Pages:Requested moves|shortcut=WP:RMCI|shortcut2=WP:RMCLOSE}}
{{Nutshell|#Don't close requested moves where you have participated in the move survey;
{{Nutshell|#Don't close requested moves if you are involved;
#If you are not an administrator you should be cautious when closing certain contentious requests;
#If you are not an administrator you should be cautious when closing contentious requests;
#Determine ] on the request or relist it for further discussion; #Determine ] on the request or relist it for further discussion;
#Investigate the page history of the target page title; if ''minor'', it may be deleted; if ''major'', perform a ], ], or archive and place a link on the talk page; #Investigate the page history of the target page title; if ''minor'', it may be deleted; if ''major'', perform a ], ], or archive and place a link on the talk page;
#Close the move request on the talk page using {{tls|RM top}} and {{tls|RM bottom}}.
#Clean up after the move by fixing all ], ] of images included on the moved page, the page's ], and the talk page archiving;
#If renamed then ]
#Formally close the move request on the talk page using {{tl|rmt}} and {{tl|rmb}}.
|shortcut=WP:RMCI
|shortcut2=WP:RM/CI
|shortcut3=WP:RMAI
|shortcut4=WP:RM/AI
}} }}
{{Notice|Note to closers: according to an ] of June 2009, ] in September 2011, discussions relating to the naming of Ireland articles (], ], ]) must occur at ], unless it is agreed there to hold the discussion elsewhere.<!--It might be moved to a sub page etc.--> Any requested move affecting these articles that is opened on the article talk pages or any other venue should be speedily closed, with a link to the ArbCom ruling.}}


The following are guidelines for closing ] discussions. Please only apply these after the normal seven day listing period has elapsed. These guidelines are addressed to formal move requests that occur on talk pages, i.e. ''controversial'' move requests, but are instructive as to the necessary page history investigation and preservation and cleanup procedures advisable upon any move. Requests listed in the ] section can be simply removed after they have been processed. Where technical moves are contested, move the listing to the ]. The following are suggestions for closing ] discussions. These should generally be applied only after the normal seven-day listing period has elapsed. These suggestions are addressed to formal move requests that occur on talk pages, i.e. ''controversial'' move requests, but are instructive as to the necessary page history investigation and preservation and cleanup procedures advisable upon any move. Requests listed in the ] section can be simply removed after they have been processed. Where technical moves are contested, move the listing to the ].


Failure of an RM closer to follow the spirit and intent of these instructions, especially about ], may result in the initiation of a ''']'''. Failure of an RM closer to follow the spirit and intent of these instructions, especially about ], may result in the initiation of a ''']'''.

Closers may find ] helpful when considering the technical task of closing a discussion.


==Who can close requested moves== ==Who can close requested moves==

===Conflicts of interest=== ===Conflicts of interest===
In closing a discussion, it is important to avoid conflicts of interest, because such circumstances cast doubt on the fairness of the closure, and often make the closure unstable. Even the appearance of conflict of interest is worth avoiding, for the same reason. Remember that there is no harm in erring on the side of caution.


An ] editor, whether an administrator or otherwise, may '''not''' close a move request (with certain exceptions, detailed below).
Apparent conflicts of interest can arise in different ways:
* Any editor who has participated in a move discussion, either in support of the move or in opposition to it, will very likely be seen as a biased judge of that discussion.
* An editor who has previously closed a move request relating to the same article may be seen as biased, especially if the previous request they closed is similar to the new request.
* Conflicts of interest may arise, or appear to arise, in many ways, and it is good to be alert to these possible circumstances.


You are considered involved{{efn|Note that these criteria are significantly stricter than the criteria listed at WP:INVOLVED; this is intentional, befitting the less urgent nature of requested moves.}} if:
No user, whether an administrator or otherwise, should ever close an unwithdrawn requested move discussion in which they supported or opposed, and in which the result of discussion is not a unanimous result. However, it is fine for a discussion participant to close a requested move in the following circumstances:
* If the discussion reaches a unanimous result after a full listing period (seven days).
* If the nominator wishes to withdraw a proposal about which no one has yet commented, or which is unanimously opposed. In this case, the nominator may close the discussion as "withdrawn".
* If the closer's participation in the discussion has been limited to clarifying questions, or is otherwise neutral with respect to the proposed move.


* You have ever opened a request to move the page
If any question of conflict of interest does arise, the best solution is for the potentially conflicted editor to recuse him or herself from closing the discussion, and leave it to someone who is more clearly neutral.
* You have ever supported or opposed a request to move the page
* You have ever closed a previous controversial request to move the page
* You have ever ] moved the page to a title you prefer (i.e., not including reverting ] or performing a ])
* You have ever commented on any talk page in a way that has indicated a clear position on the specific move request
* Your editing on the page has demonstrated a clear position on the move request


An involved editor may comment in a move discussion, solicit a closure, or make a new move request at a later date, but may not close an open move request. When you are an involved editor, trust the process and leave the close to one of the many, many other editors on Misplaced Pages who are capable of closing move discussions.
For discussions that appear to be particularly contentious, it often is best to ask at the ] for an impartial administrator to assess consensus. Such an administrator should be familiar with the relevant policies and guidelines (especially ] and ]) and move request procedures. It is highly advised to avoid asking a specific administrator to close in such circumstances, and it is generally unhelpful to solicit a closer before the move request has neared the time for closure.

If you wish to solicit a closure after at least a week of discussion has taken place, you can ] for an impartial administrator to assess consensus. The closer should be familiar with all relevant policies and guidelines (especially those relating to ] and ]) as well as the procedures described on this page. Do not ask for a specific closer under any circumstances.


===Non-admin closure=== ===Non-admin closure===
{{shortcut|WP:RMNAC}} {{shortcut|WP:RMNAC}}
Experienced and uninvolved registered editors in good standing are allowed to close requested move surveys. Any non-admin closure must be explicitly declared with template {{tl|RMnac}} placed directly after the reasoning for the close within the {{tl|rmt}} template. Experienced and uninvolved registered editors in good standing are encouraged to close requested move discussions. Any non-admin closure (NAC) must be explicitly declared with an appropriate template (such as {{tls|RMnac}}) placed directly after the reasoning for the close within the {{tls|RM top}} template (or use the {{para|nac}} parameter in the closing template).

Non-administrators are reminded that closing a discussion calls for an impartial assessment of consensus or lack thereof, although arguments supported by directly relevant policy and guidelines are given more weight (while keeping broader Misplaced Pages policy, guidelines, and consensus in mind). Any editor wishing to express an opinion on the requested move should join the discussion, not close it.

Anyone, administrator or not, who wishes to close a requested move must be very familiar with the policies and guidelines associated with it (especially ], ], and ]), and ideally will have participated in several move requests previously. All closures of requested moves are subject to being taken to review at ] (]), but assuming the criteria above are met, the mere fact that the closer was not an admin is not sufficient reason to reverse a closure. Indeed, many high-profile, controversial move requests have been closed as NACs, taken to ], and affirmed there. While non-admins should be cautious (as indeed all move closers should be) when closing discussions where significant contentious debate among participants is unresolved, any experienced and uninvolved editor in good standing may close any RM debate.

Occasionally, a move involves a redirect with multiple revisions, and requires technical intervention. Editors are permitted to close the discussion and file a ] with a link to the closed discussion. The results of discussions in favor of moves should generally be respected by the administrator (or page mover). If an administrator notices a clearly improper move closure, they should revert the closure and re-open the discussion.

In any case where a non-admin closer does resort to a technical move request, the closer should actively monitor that request, and be ready and willing to perform all tidying after the move (as ]), such as updating fair-use rationales and navbox links included on the page. If a non-admin closer is not willing to wait for the technical deletion and to perform the follow up in this manner, they should only close requested moves that do not require technical intervention.


====Closure by a page mover====
Non-admin closes normally require that:
{{see|Misplaced Pages:Page mover|Template:RMnac}}
*The consensus or lack of consensus is clear after a full listing period (seven days).
{{shortcut|WP:RMPMC}}
<!--I'm commenting out this one because if consensus is clear, this can be taken easily to WP:RMT or through other processes. The criterion was: *No history merge or history swap is necessary. -->
Editors with the page mover permission can perform certain technical moves without administrator assistance, such as a move over a redirect with more than one edit via a ] page swap. A user is granted the page mover right after demonstrating a good understanding of the Misplaced Pages page naming system and decent page moving experience. Since closure by a page mover is a type of non-admin closure, it should be labeled as such using {{tls|RMnac}}, {{tls|RMpmc}} or equivalent (or use the {{para|pmc}} parameter in the closing template).
*There are no more than a few associated subpages that need to be moved along with the move of the page under discussion, such as voluminous talk page archives. (Administrators have the ability to move up to 100 pages in a single click.)
*The move doesn't require deleting any pages in the way.


===Early closure===
Non-administrators are reminded that closing a discussion calls for an impartial assessment of consensus or lack of consensus, through arguments supported by directly relevant policy and guidelines (while keeping broader Misplaced Pages policy, guidelines, and consensus in mind). Any editor wishing to express an opinion on the requested move should join the discussion, not close it.
{{shortcut|WP:RMEC}}
In general, move discussions should remain open for at least seven days (168 hours) to allow interested editors adequate time to participate. However, when no one has commented yet, or if opposition is unanimous, discussions may be closed prior to the seven-day timeframe for the following reasons:
* As long as no one has suggested any outcome besides ''not moving'', the ''proposer'' of a move may withdraw their request. The closure should say that the request was '''withdrawn'''.
* Further, any editor may end such a move request with a '''procedural close''' if the request was initiated via ].


Under those two circumstances, it is fine for the closer to have been involved in the discussion.
Many editors do not approve of non-admins closing contentious debates. Non-admins should be cautious when closing discussions where significant contentious debate among participants is unresolved. All closures of requested moves are subject to being taken to review at ], but the mere fact that the closer was not an admin is not sufficient reason to reverse a closure.


Additionally, when the outcome of the move discussion is, or has become, almost certain, such that there is not a "snowball's chance in hell" that the outcome will be anything other than what is expected, and there is clearly no need at all to prolong discussion further, the discussion may be closed early under the ''']'''.
Where a move is not technically possible without administrative intervention, non-admins closing a discussion and then tagging the redirect with {{tlx|db-move|<nowiki>1=PAGE TO BE MOVED HERE|2=REASON FOR MOVE</nowiki>}} should actively monitor that speedy deletion request, and be ready and willing to perform all tidying after the move (as ]), such as fixing all double redirects created and fixing fair use rationales of images included on the page.
* This clause should not be used to close a discussion when a particular outcome is merely "likely" or "highly likely", and there is a genuine and reasoned basis for disagreement. This is because move discussions are not a vote; it is important to be reasonably sure that there is little or no chance of accidentally excluding significant input or perspectives, or changing the weight of different views, if closed early. Especially, closers should beware of interpreting "early pile on" as necessarily showing how a discussion will end up. This can sometimes happen when a topic attracts high levels of attention from those engaged (or having a specific view) but slower attention from other less involved editors, perhaps with other points of view. It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to avoid precluding significant input and as a courtesy to ensure that it really will be a snowball.


==Determining consensus== ==Determining consensus==
{{shortcut|WP:RMCIDC}}
] is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Misplaced Pages community in general as reflected in applicable policy, guidelines and naming conventions. ] is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Misplaced Pages community in general as reflected in applicable policy, guidelines and naming conventions.


{{shortcut|WP:RMNOMIN}}
Unlike ], where lack of participation requires relisting, no minimum participation is required for requested moves because for most moves there is ]; the need arises only because of a technical limitation resulting from the target article name existing as a redirect with more than one edit. Thus, if no one has objected, go ahead and perform the move as requested unless it is out of keeping with ] or is otherwise in conflict with applicable guidelines or policy. Further, any move request that is out of keeping with ] or is otherwise in conflict with applicable guideline and policy, unless there is a very good reason to ], should be closed without moving regardless of how many of the participants support it. Remember, the participants in any given discussion represent only a tiny fraction of the Misplaced Pages community whose consensus is reflected in the policy, guidelines and conventions to which all titles are to adhere. Thus, closers are expected to be familiar with such matters, so that they have the ability to make these assessments.
'''{{vanchor|No minimum participation is required}}''' for requested moves. If no one has objected, go ahead and perform the move as requested unless it is out of keeping with ] or is otherwise in conflict with applicable guidelines or policy. Further, any move request that is out of keeping with ] or is otherwise in conflict with applicable guideline and policy, unless there is a very good reason to ], should be closed without moving regardless of how many of the participants support it. Remember, the participants in any given discussion represent only a tiny fraction of the Misplaced Pages community whose consensus is reflected in the policy, guidelines and conventions to which all titles are to adhere. Thus, closers are expected to be familiar with such matters, so that they have the ability to make these assessments.


If objections have been raised, then the discussion should be evaluated just like any other discussion on Misplaced Pages: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority). However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if no consensus has been reached, the closer should move the article back to the most recent stable title. If no recent title has been stable, then the article should be moved to the title used by the first major contributor after the article ceased to be a stub. If objections have been raised, then the discussion should be evaluated just like any other discussion on Misplaced Pages: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority). However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if no consensus has been reached, the closer should move the article back to the most recent stable title. If no recent title has been stable, then the article should be moved to the title used by the first major contributor after the article ceased to be a stub.


{{shortcut|WP:RMNCREV}}{{anchor|RM no consensus revert}}
Note that according to {{section link|Misplaced Pages:Consensus|No consensus}}: Note that according to {{section link|Misplaced Pages:Consensus|No consensus}}:
{{cquote|When article title discussions end without consensus, the ] preserves the most recent stable title. If there is no prior stable title, then the default is the title used by the first major contributor after the article ceased to be a ].}}


Therefore, if a page has been moved from a long-standing title, and it is not possible to move the page back to its original title during the discussion, the default title will be the title prior to the contested move. For example, if an article is created at ] and stays there for years prior to being ]ly moved to ], and a move request is filed leading to a decision of "no consensus", the article must be moved back to its longstanding title. This is the case even if the ''original'' page was placed at ] or ] or ], as long as ] took over through consensus and can be determined to be the actual long-standing title.
{{cquote|In article title discussions, ''no consensus'' has two defaults: If an article title has been stable for a long time, then the long-standing article title is kept. If it has never been stable, or has been unstable for a long time, then it is moved to the title used by the first major contributor after the article ceased to be a stub.}}

Therefore, if a page has been moved from a longstanding title, and it is not possible to move the page back to its original title during the discussion, the default title will be the title prior to the contested move. For example, if an article is created at ] and stays there for years prior to being ]ly moved to ], and a move request is filed leading to a decision of "no consensus", the article must be moved back to its longstanding title. This is the case even if the ''original'' page was placed at ] or ] or ], as long as ] took over shortly afterwards and can be determined to be the actual long-standing title.


===Relisting=== ===Relisting===
{{See also|Misplaced Pages:Requested moves#Relisting}} {{For|the instructions on relisting move discussions|Misplaced Pages:Requested moves#Relisting a requested move}}
Relisting is an option when a discussion cannot otherwise be closed, usually due to lack of consensus. Editors are under no obligation to wait to close a move request after it is relisted. Once a move request has been open for the full seven days, it may be closed at any time by an uninvolved editor. Closers wait mainly for general agreement, for consensus, to emerge.


'''Exception:''' if a page is added while relisting. Sometimes editors may not realize that to move page A to B, page B must first be moved to C. When a new page move request is added to one that is already seven days old, the RMCD bot places the notification tag on the newly added page that day, and the discussion must go a full seven days (more) before being closed. It is helpful to closers when relisters leave a note just below the nomination that this happened.
If a discussion is ongoing or has not reached a reasonable conclusion, you may elect to re-list the discussion, though it is entirely optional and up to the closer. Relisting simply consists of stating <tt><nowiki>Relisted. ~~~~</nowiki></tt> before the initial requester's first timestamp (see for an example), or the previous relisting comment. This gives the request a new timestamp which ] will use as the date to relist the entry on the requested moves project page. This can be done using {{tlx|relisting|subst=y}}, which also signs it automatically.


====Relisting and participating====
== Moving procedures ==
===Edit history of destination page===
The majority of target names for move requests already exist as ] to the present names. Whether a redirect or otherwise, that existing target title should be investigated to see whether it has a minor or major ]. If it has a ''minor'' page history, generally meaning it only existed as a redirect, and was never a duplicate article, never had content that was cut and pasted to the present title, nor merged there, ''it may simply be deleted.'' However, if the target page title has a ''major'' history it should '''never''' be simply deleted, as we need to retain such page histories for proper ] attribution. There are three ways to deal with target pages with major histories, dependent on circumstances. In the event this situation presents itself on a move, click "show" below for instructions.
{{hidden begin
|title = Procedure for redirects with major histories
|titlestyle = background:AntiqueWhite; text-align:center;
}}
# For page histories resulting from cut and paste moves, the ''correct'' way to fix this is to merge the page history of the present article and the redirect, using the procedure outlined at ]. On rare occasions, this procedure will not work correctly. Once a history merge is done, it cannot easily be undone, so don't pick this option unless it is definitely the right one. You can request history merges at ].
# For duplicate articles and merged content, or alternatively for cut and paste moves, the page histories of the article and the redirect can be swapped. For cut and paste moves this leaves a bifurcated history, but has less chance of causing problems. Simply move one of the pair to a temporary name (<code>NAME''/temp''</code> is suggested), suppressing the creation of a redirect (in the event you forget to suppress the redirect, delete the same); next, move the other page of the pair across to the first one's old location, again suppressing the redirect and deleting the same if you forget; next, move the first page from its temporary location to its new name. Finally, fix the old redirect to point at the article again (at this point, it will be pointing to itself). See also ].
# Another option is for redirect pages with major histories to be archived into a talk namespace, and a link then placed on the article's ]. (An example of such a page is at ], which was originally created as a duplicate article at ] and later archived, when the original article was moved from ]).
{{hidden end}}


A relister may later become a participant or closer in the requested move discussion or survey.
===Cleaning up after the move===
It is important that you clean up after any move you perform. Accordingly, you should not close any move if you are unwilling to do the necessary clean up tasks listed below.


====Fixing double redirects==== ===Only move involved pages===
A move request about moving X to Y should never be closed in such a way as to require page Z to move if Z wasn't listed in the original move request (see ]). <!--This rule has been in place, in one way or another, since 2014. Please do not remove without discussion.-->
Moving a page changes any ] that pointed to the original page location, into ]. These make for an unpleasant experiences for the reader, waste server resources, and make the navigational structure of the site confusing. It is the responsibility of the closer to fix these. Periodically a bot will attempt to fix any double redirects missed but that does not relieve the closer of the responsibility which should be handled soon after the move.


Where a discussion would result in the original title pointing to a "Foo (disambiguation)" page, the practice of pagemovers has been to immediately move the disambiguation page to the base page name, per ]. This is because a disambiguation page is presumed to belong at the base page name unless that title is taken by a primary topic.
The "move succeeded" summary page that you are taken to directly upon a move provides a link entitled "Check what links here" specifically geared to listing offending double redirects created by a move. ] shown on the resulting page.


=={{anchor|Three possible outcomes}}Write a clear, concise closing statement==
Some talk pages, archive pages and subpages that you may also have moved, may also have had redirects that have become double redirects. These associated moved pages are listed at the bottom of the move succeeded page. Open up the prior page names (which should now be themselves all at redirects) and click on "What links here" in the toolbox on the left hand side of the page, then click on "Hide transclusions" and "Hide links". This is the manual procedure to perform the same search the move succeeded page provides with the "Check what links here" link noted above.
<!-- This Anchor tag serves to provide a permanent target for incoming section links. Please do not remove it, nor modify it, except to add another appropriate anchor. If you modify the section title, please anchor the old title. It is always best to anchor an old section header that has been changed so that links to it will not be broken. See ] for details. This template is {{subst:Anchor comment}} -->
{{shortcut|WP:THREEOUTCOMES}}
{{further|#Determining consensus}}
There are generally three different outcomes for consensus in requested moves. The closer should clearly show which outcome has taken place so that other editors may quickly see the progression of consensus regarding the title; it is much easier to move an article that has never had a firm consensus about the title.


# '''Moved''' (or '''consensus to move''') should be used when consensus ''is'' found to rename the page. If there is any question whatsoever as to ''which'' title it should be moved to, please note this in the closing summary (e.g. "'''moved to ]'''"). This almost always sets a consensus for the new title, and further requests to move the page are likely to fail unless new information or arguments are brought forth.
====Fixing fair use rationales====
# '''Not moved''' (or '''consensus not to move''') should be used when a consensus ''has'' formed to keep the current title and ''not'' rename the article(s) in question. For instance, a proposal to rename ] to ] would likely result in everyone (or nearly everyone) agreeing that the proposed move should not take place; this notifies other editors that they should probably not propose this move in the future until and unless circumstances change. There is a positive consensus found, and that consensus is for the page to stay exactly where it is.
Please check whether there are any images on the moved page with ] (any ] images can be immediately excluded, easily recognizable by the logo on the image page: ]). If you find such fair use images present, change all mentions of the prior article name, to the retitled name, so that the image is not ].
# '''No consensus''' should be used when there is neither a consensus to move ''nor'' a consensus to keep the current title. This may be because a discussion has fractured into several possible titles and none seem especially suitable, or simply because equally strong arguments and appeals to Misplaced Pages policy and outside sources were found on both sides, without any clear reason to move the page found in the discussion. Of course, as elsewhere on Misplaced Pages, this usually means that no action is to be taken at the present time.


While it is usually bad form to re-request a move if consensus ''is'' found against it (until and unless circumstances change), it is ''not'' considered bad form to re-raise a request that found "no consensus" to move. (Successful move re-requests generally, though not always, take place at least three months after the previous one. An exception is when the no-consensus move discussion suggests a clear, new course of action.)
====Fixing category sort keys====
Many pages have a template above the page categories in the form <nowiki>{{DEFAULTSORT:Name}}</nowiki> Where the name field provided in the template is the old title of the page (pages are sometimes categorized in other ways), change it to the new title. Alternatively, in some pages categories are ] in the category links themselves, e.g., <nowiki>]</nowiki>. In the example you would fix the name of the film.


===Discussions involving multiple options===
====Fixing hatnotes, DAB pages and first sentences in leads====
{{seealso|WP:Bartender}}
Though not as common as the above, a move may occasionally render a ] obsolete. The documentation page at {{tl|Hatnote templates documentation}} may be instructive in finding a suitable replacement, if one is needed (sometimes simple removal may be appropriate). Often the reason for the hatnote is because there is either a disambiguation page related to the topic, or another topic pointing to yours and vice-versa per ]. In such cases you should visit either the DAB page or the other article with the hatnote, and replace the old name of the article you have just moved, with its new name. The first sentence of the article's lead section may, following the move, need tweaking to conform the language to the changed title.
{{shortcut|WP:NOGOODOPTIONS|WP:OTHEROPTIONS}}


Most move requests are simple. Alice proposes that we move X to Y. Bob, Carol and Dave chime in. Edgar analyzes the discussion and decides whether there is a consensus, and then gives one of the three outcomes above.
====Fixing talk page archiving====
Some archiving bots, such as MiszaBot, have hardcoded page names in their archiving settings. After closing the move and moving the talk page archiving, the bot settings should be updated on the talk page to the new name of the talk page.


But sometimes things get complicated. Alice proposes moving X to Y, but then Bob raises real concerns about Y, and proposes Z instead. Carol says, no, we should stay with Y. Dave says we actually need to keep the article at X. Edgar shows up and is very confused. What does he do?
====Moves of disambiguation pages to primary topic titles====
Unlike most moves where the pages that link to the moved title will still point to it after the move because of redirects, when a ] is moved to a primary title, this severs the connection between pages which linked to the primary title. For example, if <code>Foo</code> is moved to a parenthetically disambiguated name, and <code>Foo (disambiguation)</code> is then moved to <code>Foo</code>, everything that linked to Foo, now leads to the primary disambiguation page. In such instances, significant cleanup involving hand dabbing of the pages that formerly linked to the title may be needed.


If you as a closer are in doubt because too many titles have been proposed and there's no real consensus anywhere, it is generally best to '''close as no consensus''' and allow someone to re-propose the move to a more specific or better title.
===Moves of other pages===
If a page is to be moved as the result of a move request, mention should be made of this in the move proposal and a notice should be placed on the talk page of the article to be moved (unless of course it is hosting the discussion). Generally, a move request on whether to move ] to ] should have no impact on page ]'s title, unless it is initiated as a {{tl|multi-move request}} that mentions moving Z as a possibility. This is because the editors most interested and aware of Z are not able to contribute their expertise to the naming discussion, since it's happening at a different place without any notice given.

These situations often come up when ] is proposed to move to, say, ], and someone mentions that they think the barge is actually the primary topic. A consensus of these barge enthusiasts may then informally suggest that the existing article ] be moved to ], without actually notifying Foobar-interested editors by signaling at ] that a move request involving that page is taking place. This often leads to strife and another, more contentious move request. If consensus at X signals that Z should move, close the request at ], do not move ], and file a new move request at ].

Even if consensus is clear, when closing a move request '''do not move articles that have not been nominated to be moved''' except in the very clearest and not-even-plausibly controversial situations.

==Three possible outcomes==
There are generally three different outcomes for requested moves. The closer should clearly show which outcome has taken place so that other editors may quickly see the progression of consensus regarding the title; it is much easier to move a title that has never had consensus than one that always has.

#'''NOT MOVED''' should be used when a consensus ''has'' formed to ''not'' rename the article(s) in question. For instance, a proposal to rename ] to ] would likely result in everyone (or nearly everyone) agreeing that the proposed move should not take place; this notifies other editors that they should not propose this move in the future until and unless circumstances change.

#'''NO CONSENSUS''' should be used when there is neither a strong consensus to move ''nor'' a consensus to keep the current title. This may be because a discussion has fractured into several possible titles and none seem especially suitable, or simply because equally strong arguments and appeals to Misplaced Pages policy and outside sources were found on both sides, without a clear winner in the discussion. While it is bad form to re-request a move if consensus ''is'' found against it (until and unless circumstances change), it is ''not'' considered bad form to re-raise a request that found "no consensus" to move. (Various proposals to set a specific timeframe that must be waited out before re-raising tend to fail; however, successful move re-requests almost always take place at least three months and usually at least six months after the previous one.)

#'''MOVED''' should be used when consensus ''is'' found to move. If there is any question as to ''which'' title it should be moved to, please note this in the closing summary (e.g. '''MOVED to ]'''). This almost always sets a consensus for the new title, and further requests to move the page are likely to fail unless new information is brought forth. (There are rare circumstances where multiple names have been proposed and no consensus arises out of any, except that it is determined that the current title should ''not'' host the article. In these difficult circumstances, the closer should pick the best title of the options available, and then be clear that while consensus has rejected the former title (and no request to bring it back should be made lightly), there is no consensus for the title actually chosen. Another move request may then be made ''immediately'' (but not by the closer!) to once again move the article, this time hopefully to its final resting place.)


{{anchor|NOTCURRENTTITLE}}{{shortcut|WP:NOTCURRENTTITLE}}
But then again, there are situations where multiple names have been proposed and no consensus arises out of any, except that it '''is''' determined that the current title should ''not'' host the article. (There are good arguments for Y, and there are good arguments for Z, but there are virtually ''no'' good arguments for it to stay at X.) In these difficult circumstances, the closer should pick the best title of the options available, and then make clear that while consensus has rejected the former title (and no request to bring it back should be made lightly), there is no consensus for the title actually chosen. Because such closures are inherently complex and require the closer to use more independent judgment than normal, it is ''strongly encouraged'' to provide an explicit closing statement in such closures. As this result does not indicate a consensus for the chosen title, anyone who objects to the closer's decision may make another move request ''at any time'', and is advised to create such a request instead of taking the closure to ].


==Closing the requested move== ==Closing the requested move==
When you complete an entry on the project (whether the move was accepted or rejected), remove the {{tl|requested move/dated}} tag from the talk page, or change {{tla|requested move/dated|requested move/'''dated'''}} to {{tla|requested move/old|requested move/'''old'''}}. You should also add and sign a comment to indicate whether the move was accepted or rejected in the discussion area for the requested move. This can take the form of an informal note or a more formal close (see below). When you complete an entry on the project (whether the move was accepted or rejected), '''remove the {{tl|requested move/dated}} tag from the talk page''', or change {{tla|requested move/dated|requested move/'''dated'''}} to <nowiki>{{</nowiki>]:]}}. You should also add and sign a comment to indicate whether the move was accepted or rejected in the discussion area for the requested move. To ease things a little bit, there are several scripts that can help, with the most common being ] (followed by ] and ]).


There are a few options for formally closing the move request survey on the affected article's talk page. One is to use the templates {{tlxs|RM top|'''result of the discussion'''.}} and {{tls|RM bottom}}. The other is just to leave a statement like "''This article has been renamed per the above ]''". For requests that for some reason did not apply, you can use {{tls|notmovedmalformed}} or a similar statement based on the circumstances. While historically, there have been other options for closing the move request survey on the affected article's talk page, nowadays we exclusively use the twin templates {{tlxs|RM top|'''result of the discussion'''.}} and {{tls|RM bottom}}.


===Step-by-step formal closing procedure=== ===Step-by-step closing procedure===
After clicking the tab next to the move discussion, you may follow these step-by-step instructions for closing an RM discussion: After clicking the tab next to the move discussion, you may follow these step-by-step instructions for closing an RM discussion:
{|class="wikitable" style="font-size: 90%; text-align: center; width: 100%;" {|class="wikitable" style="font-size: 90%; text-align: center; width: 100%;"
Line 137: Line 131:
| style="background-color: lightgray"|<nowiki>==Requested move==</nowiki> | style="background-color: lightgray"|<nowiki>==Requested move==</nowiki>
| style="background-color: lightgray"|<nowiki>==Requested move==</nowiki> | style="background-color: lightgray"|<nowiki>==Requested move==</nowiki>
|Leave the header alone; the close starts below it. |Leave the heading alone; the close starts below it.
|- |-
| style="background-color: yellow"|<nowiki>{{Requested move/dated|Foo}}</nowiki> | style="background-color: yellow"|<nowiki>{{Requested move/dated|Foo}}</nowiki>
| style="background-color: lightgreen"|<nowiki>{{subst:RM top|'''RESULT.'''}}</nowiki> | style="background-color: lightgreen"|<nowiki>{{subst:RM top|'''RESULT.'''</nowiki><span class="anonymous-show extendedconfirmed-show">{{!}}<span class="extendedmover-show">pm</span>nac=yes</span><nowiki>}}</nowiki>
|Replace text on left with text on right. Add {{Template|RMnac}} ''within the template'' if necessary. |Replace text on left with text on right.
|- |-
|style="background-color: lightgray"|''DISCUSSION'' |style="background-color: lightgray"|''DISCUSSION''
Line 157: Line 151:
After closing, the page should look similar to this: After closing, the page should look similar to this:


<div class="boilerplate mw-archivedtalk" style="background-color: var(--background-color-success-subtle, #efe); color: var(--color-base, #000); margin: 0; padding: 0 10px 0 10px; border: 1px dotted var(--border-color-subtle, #AAAAAA);"><!-- Template:RM top -->
<div style="padding:2.0em;background:antiquewhite;"><!--to show that this div is an example rather than a subsection of this page
:''The following is a closed discussion of a ]. <span style="color: var(--color-error, red);">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a ] after discussing it on the closer's talk page. No further edits should be made to this discussion.''
-->{{resize|150%|Requested move}}
<hr/>
<div class="boilerplate" style="background-color: #efe; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px dotted #aaa;"><!-- Template:RM top -->
:''The following discussion is an archived discussion of a ]. <span style="color:red">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a ]. No further edits should be made to this section. ''


The result of the move request was: '''RESULT'''. . ] (]) {{CURRENTTIME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (UTC)<br> The result of the move request was: '''RESULT'''. . <span class="anonymous-show extendedconfirmed-show"><small>(])</small> </span>] (]) {{CURRENTTIME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (UTC)
---- ----
] → {{no redirect|1=Foobar}} – rationale of nominator. ] (]) {{CURRENTTIME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (UTC)<br> ] → {{no redirect|1=Foobar}} – rationale of nominator. ] (]) {{CURRENTTIME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (UTC)
*'''Supports/Opposes''' with discussion *'''Supports/Opposes''' with discussion
{{RM bottom}} {{RM bottom}}
Line 171: Line 162:
</div> </div>


===Add {{tl|Oldmoves}} or {{tl|Old move}} to the talk page=== ===Add {{tl|Old moves}} to the talk page if so desired===
After the move is complete, the {{tl|Oldmoves}} or {{tl|Old move}} templates can be added to the top of the talk page (or updated if already present), allowing editors to see previous move discussions that might otherwise be archived. This is helpful for titles that are likely to be challenged again, so that any would-be re-proposer can make reference to previous arguments and consider how a consensus may be formed to move. In the case of pages with multiple move discussions, these templates should always be added/updated after the closure of an RM. After the move is complete, the {{tl|Old moves}} template may be added to the top of the talk page (or updated if already present), allowing editors to see previous move discussions that might otherwise be archived. This is helpful for titles that are likely to be challenged again, so that any would-be re-proposer can make reference to previous arguments and consider how a consensus may be formed to move. In the case of pages with multiple move discussions, these templates should always be added/updated after the closure of an RM.


===Automatic removals===
===Automatic removal of request from ] page===
Once the article's talk page has been updated, there's no need to return to the ] page and delete the article's entry there; this will be performed automatically by a bot. Once the article's talk page has been updated, there's no need to return to the ] page and delete the article's entry there; this will be performed automatically by a bot.

Likewise, {{u|RMCD bot}} will remove the {{tl|Title notice}} from the page itself within 15 minutes.


===Using move protection during RMs and immediately after RM closes=== ===Using move protection during RMs and immediately after RM closes===
{{see also|WP:MOVP}} {{see also|WP:MOVP}}
Some RM discussions are contentious; un-discussed, unilateral page moves during a discussion or page moves made immediately after and contrary to an RM close decision are disruptive and hurt the integrity of the RM process. Admins monitoring RM discussions should use their discretion to ''move protect'' articles during contentious RM discussions when they believe a premature, un-discussed unilateral move would be disruptive to the discussion. The same discretion should be used to start or continue move protection immediately after the RM close. Generally, such move protection should be limited to no more than 30 days under normal circumstances. The RM closing comment should reference the move protection. Some RM discussions are contentious; undiscussed, unilateral page moves during a discussion or page moves made immediately after and contrary to an RM close decision are disruptive and hurt the integrity of the RM process. Admins monitoring RM discussions should use their discretion to ''move protect'' articles during contentious RM discussions when they believe a premature, undiscussed unilateral move would be disruptive to the discussion. The same discretion should be used to start or continue move protection immediately after the RM close. Generally, such move protection should be limited to no more than 30 days under normal circumstances. The RM closing comment should reference the move protection.

== Moving procedures ==
===Edit history of destination page===
The majority of target names for move requests already exist as ] to the present names. Whether a redirect or otherwise, that existing target title should be investigated to see whether it has a minor or major ]. If it has a ''minor'' page history, generally meaning it only existed as a redirect, and was never a duplicate article, never had content that was cut and pasted to the present title, nor merged there, ''it may simply be deleted.'' However, if the target page title has a ''major'' history it should '''never''' be simply deleted, as we need to retain such page histories for proper ] attribution. There are three ways to deal with target pages with major histories, dependent on circumstances. In the event this situation presents itself on a move, click "show" below for instructions.
{{hidden begin
|title = Procedure for redirects with major histories
|titlestyle = background:AntiqueWhite; text-align:center;
}}
# For page histories resulting from cut and paste moves, the ''correct'' way to fix this is to merge the page history of the present article and the redirect, using the procedure outlined at ]. On rare occasions, this procedure will not work correctly. Once a history merge is done, it cannot easily be undone, so don't pick this option unless it is definitely the right one. You can request history merges at ].
# For duplicate articles and merged content, or alternatively for cut and paste moves, the page histories of the article and the redirect can be swapped with a round-robin move. For cut and paste moves this leaves a bifurcated history, but has less chance of causing problems. Simply move the redirect with a major history to a temporary name (<code>Draft:Move/''NAME''</code> is suggested), suppressing the creation of a redirect (in the event you forget to suppress the redirect, delete the same); next, move the article to the move target location, again suppressing the redirect and deleting the same if you forget; next, move the redirect from its temporary location to the title at which the article you just moved was formerly located. At this point the redirect will be pointing at itself; re-target it to point to the new location of the article. See also ] and ].
# Another option is for redirect pages with major histories to be archived into a talk namespace, and a link then placed on the article's ]. (An example of such a page is at ], which was originally created as a duplicate article at ] and later archived, when the original article was moved from ]).
{{hidden end}}

===Cleaning up after the move===
{{main|Misplaced Pages:Cleaning up after a move}}

You should not close any move if you are unwilling to do the necessary clean up tasks described at ]. Some of the most commonly required cleanup tasks are:
* Updating the article prose (including the ]) to use the new name
* Updating any navigational templates to link directly to the new title, ]
* Fixing any mistargeted wikilinks resulting from the move (only applies when the move involves a change to primary topic)

===Moves of other pages{{anchor|NOTOTHERPAGES}}===
{{shortcut|WP:NOTOTHERPAGES}}
If a page is to be moved as the result of a move request, mention should be made of this in the move proposal and a notice should be placed on the talk page of the article to be moved (unless of course it is hosting the discussion). Generally, a move request on whether to move ] to ] should have no impact on page ]'s title, unless it is initiated as a {{tl|multi-move request}} that mentions moving Z as a possibility. This is because the editors most interested and aware of Z are not able to contribute their expertise to the naming discussion, since it's happening at a different place without any notice given.

These situations often come up when ] is proposed to move to, say, ], and someone mentions that they think the barge is actually the primary topic. A consensus of these barge enthusiasts may then informally suggest that the existing article ] be moved to ], without actually notifying Foobar-interested editors by signaling at ] that a move request involving that page is taking place. This often leads to strife and another, more contentious move request. If consensus at X signals that Z should move, close the request at ], do not move ], and file a new move request at ].

Even if consensus is clear, when closing a move request '''do not move articles that have not been nominated to be moved''' except in the very clearest and not-even-plausibly controversial situations.


==Bot considerations== ==Bot considerations==
Line 186: Line 207:
A request will be listed in a special section titled ''"Malformed requests"'' on ] when the listing bot fails to successfully interpret the request. Please remember to use {{tlsx|Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include: A request will be listed in a special section titled ''"Malformed requests"'' on ] when the listing bot fails to successfully interpret the request. Please remember to use {{tlsx|Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:
*The request was appended to an existing talk page section. Add a new section header immediately above the {{tlx|Requested move/dated}} template. *The request was appended to an existing talk page section. Add a new section header immediately above the {{tlx|Requested move/dated}} template.
*Text was inserted between the section header and the {{tlx|Requested move/dated}} template. Move that text above the section header or below the request, or remove it.
*Look for a blank space after the section header == equal signs, including on the line following the heading, and remove any.
*It is OK to change the auto-generated level 2 header to a level 3 header, thus making the RM section a sub-section of an earlier-started discussion. *It is OK to change the auto-generated level 2 header to a level 3 header, thus making the RM section a sub-section of an earlier-started discussion.
*The page requested to be moved is a ]. Only pages with non-redirecting content should be requested to be moved.
*Per ] the timestamp must adhere to the system-generated format (<code>HH:MM, D MM YYYY (UTC)</code>) and must not be customized.


=== "Time could not be ascertained"=== === "Time could not be ascertained"===
A request will be listed in a special section titled ''"Time could not be ascertained"'' on ] when the listing bot cannot ascertain the date on which the request was made. Please remember to use {{tlsx|Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include: A request will be listed in a special section titled ''"Time could not be ascertained"'' on ] when the listing bot cannot ascertain the date on which the request was made. Please remember to use {{tlsx|Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:
*The move request is not signed. Sign the move request, and the problem is solved. If you are signing for someone else and you use {{tl|Unsigned}}, you must place today's time/date stamp for this to remedy the problem, so you can use the form <nowiki>{{subst:unsigned|Foo|~~~~~}}</nowiki>, and note this uses ''five'' tildes to place the time stamp, or the actual timestamp can be copied from history - but adding (UTC) is required, and the ] must be ]: position your mouse pointer just to the right of the year <code>{{CURRENTYEAR}}</code> and press {{keypress|Backspace}} ''once'' - if the last number "{{str index|{{CURRENTYEAR}}|4}}" is not deleted, then you have probably deleted the hidden left-to-right mark, and {{keypress|Show preview}} will confirm the change before you save it. *The move request is not signed. Sign the move request, and the problem is solved. If you are signing for someone else and you use {{tl|Unsigned}}, you must place today's time/date stamp for this to remedy the problem, so you can use the form <nowiki>{{subst:unsigned|Foo|~~~~~}}</nowiki>, and note this uses ''five'' tildes to place the time stamp, or the actual timestamp can be copied from history - but adding (UTC) is required.<br>Also remove the <code><nowiki><!-- Template:Unsigned --></nowiki></code> comment from the end of the line – the bot allows up to 23 bytes following the timestamp at the end of the line, and that comment is 26 bytes long.
*A missing &ndash; between the proposed move and the proposal description will prevent the description from appearing. This can be fixed by simply adding the missing &amp;ndash;. *A missing "&ndash;" (]) between the proposed move and the proposal description will prevent the description from appearing. This can be fixed by simply adding the missing endash.
*Unusually formatted signatures will prevent recognizing the end of the proposal description, for example, if the date is formatted Month Day, Year instead of Day Month Year. This can be fixed by editing the timestamp or adding a formatted time stamp.{{diff|Misplaced Pages:Requested moves/Current discussions|529383718|529367455}} In the first case, December 20, 2012 was changed to 20 December 2012, in the second case, a second time stamp was added. *Unusually formatted signatures will prevent recognizing the end of the proposal description, for example, if the date is formatted Month Day, Year instead of Day Month Year. This can be fixed by editing the timestamp or adding a formatted time stamp.{{diff|Misplaced Pages:Requested moves/Current discussions|529383718|529367455}} In the first case, December 20, 2012 was changed to 20 December 2012, in the second case, a second time stamp was added.


Line 199: Line 220:
Occasionally two sections with the same ] will appear on a talk page. When this happens, the bot will link to the first one, even if the current move request is the second one. This can be remedied by giving the section containing the current move request a different name, such as "Requested move 2", or by giving the older section a different name, like "Requested move (month year)". A duplicate header for the same discussion can be deleted. Occasionally two sections with the same ] will appear on a talk page. When this happens, the bot will link to the first one, even if the current move request is the second one. This can be remedied by giving the section containing the current move request a different name, such as "Requested move 2", or by giving the older section a different name, like "Requested move (month year)". A duplicate header for the same discussion can be deleted.


===Arrows=== ==Notes==
{{notelist}}
Do not use the right-arrow character (→) between links in the reason for moving the page, as this confuses the bot's pattern-matching. The characters (–>) or similar may be used as a work-around.



] ]

Latest revision as of 14:57, 6 December 2024

This is an explanatory essay about Misplaced Pages:Requested moves.
This page provides additional information about concepts in the page(s) it supplements. This page is not one of Misplaced Pages's policies or guidelines as it has not been thoroughly vetted by the community.		Shortcuts
Explanatory essay about Misplaced Pages:Requested moves
This page in a nutshell:
  1. Don't close requested moves if you are involved;
  2. If you are not an administrator you should be cautious when closing contentious requests;
  3. Determine consensus on the request or relist it for further discussion;
  4. Investigate the page history of the target page title; if minor, it may be deleted; if major, perform a history merge, history swap, or archive and place a link on the talk page;
  5. Close the move request on the talk page using {{subst:RM top}} and {{subst:RM bottom}}.
  6. If renamed then clean up after the move

The following are suggestions for closing Misplaced Pages:Requested moves discussions. These should generally be applied only after the normal seven-day listing period has elapsed. These suggestions are addressed to formal move requests that occur on talk pages, i.e. controversial move requests, but are instructive as to the necessary page history investigation and preservation and cleanup procedures advisable upon any move. Requests listed in the technical requests section can be simply removed after they have been processed. Where technical moves are contested, move the listing to the contested technical requests section.

Failure of an RM closer to follow the spirit and intent of these instructions, especially about properly weighing consensus with applicable policies and guidelines, may result in the initiation of a Move Review.

Closers may find this guide helpful when considering the technical task of closing a discussion.

Who can close requested moves

Conflicts of interest

An involved editor, whether an administrator or otherwise, may not close a move request (with certain exceptions, detailed below).

You are considered involved if:

  • You have ever opened a request to move the page
  • You have ever supported or opposed a request to move the page
  • You have ever closed a previous controversial request to move the page
  • You have ever boldly moved the page to a title you prefer (i.e., not including reverting page move vandalism or performing a technical request)
  • You have ever commented on any talk page in a way that has indicated a clear position on the specific move request
  • Your editing on the page has demonstrated a clear position on the move request

An involved editor may comment in a move discussion, solicit a closure, or make a new move request at a later date, but may not close an open move request. When you are an involved editor, trust the process and leave the close to one of the many, many other editors on Misplaced Pages who are capable of closing move discussions.

If you wish to solicit a closure after at least a week of discussion has taken place, you can make a request for an impartial administrator to assess consensus. The closer should be familiar with all relevant policies and guidelines (especially those relating to article titles and disambiguation) as well as the procedures described on this page. Do not ask for a specific closer under any circumstances.

Non-admin closure

Shortcut

Experienced and uninvolved registered editors in good standing are encouraged to close requested move discussions. Any non-admin closure (NAC) must be explicitly declared with an appropriate template (such as {{subst:RMnac}}) placed directly after the reasoning for the close within the {{subst:RM top}} template (or use the |nac= parameter in the closing template).

Non-administrators are reminded that closing a discussion calls for an impartial assessment of consensus or lack thereof, although arguments supported by directly relevant policy and guidelines are given more weight (while keeping broader Misplaced Pages policy, guidelines, and consensus in mind). Any editor wishing to express an opinion on the requested move should join the discussion, not close it.

Anyone, administrator or not, who wishes to close a requested move must be very familiar with the policies and guidelines associated with it (especially Misplaced Pages:Article titles, Misplaced Pages:Disambiguation, and Misplaced Pages:Consensus), and ideally will have participated in several move requests previously. All closures of requested moves are subject to being taken to review at WP:Move review (WP:MRV), but assuming the criteria above are met, the mere fact that the closer was not an admin is not sufficient reason to reverse a closure. Indeed, many high-profile, controversial move requests have been closed as NACs, taken to WP:MRV, and affirmed there. While non-admins should be cautious (as indeed all move closers should be) when closing discussions where significant contentious debate among participants is unresolved, any experienced and uninvolved editor in good standing may close any RM debate.

Occasionally, a move involves a redirect with multiple revisions, and requires technical intervention. Editors are permitted to close the discussion and file a technical move with a link to the closed discussion. The results of discussions in favor of moves should generally be respected by the administrator (or page mover). If an administrator notices a clearly improper move closure, they should revert the closure and re-open the discussion.

In any case where a non-admin closer does resort to a technical move request, the closer should actively monitor that request, and be ready and willing to perform all tidying after the move (as instructed below), such as updating fair-use rationales and navbox links included on the page. If a non-admin closer is not willing to wait for the technical deletion and to perform the follow up in this manner, they should only close requested moves that do not require technical intervention.

Closure by a page mover

Further information: Misplaced Pages:Page mover and Template:RMnac Shortcut

Editors with the page mover permission can perform certain technical moves without administrator assistance, such as a move over a redirect with more than one edit via a round-robin page swap. A user is granted the page mover right after demonstrating a good understanding of the Misplaced Pages page naming system and decent page moving experience. Since closure by a page mover is a type of non-admin closure, it should be labeled as such using {{subst:RMnac}}, {{subst:RMpmc}} or equivalent (or use the |pmc= parameter in the closing template).

Early closure

Shortcut

In general, move discussions should remain open for at least seven days (168 hours) to allow interested editors adequate time to participate. However, when no one has commented yet, or if opposition is unanimous, discussions may be closed prior to the seven-day timeframe for the following reasons:

  • As long as no one has suggested any outcome besides not moving, the proposer of a move may withdraw their request. The closure should say that the request was withdrawn.
  • Further, any editor may end such a move request with a procedural close if the request was initiated via block evasion.

Under those two circumstances, it is fine for the closer to have been involved in the discussion.

Additionally, when the outcome of the move discussion is, or has become, almost certain, such that there is not a "snowball's chance in hell" that the outcome will be anything other than what is expected, and there is clearly no need at all to prolong discussion further, the discussion may be closed early under the snowball clause.

  • This clause should not be used to close a discussion when a particular outcome is merely "likely" or "highly likely", and there is a genuine and reasoned basis for disagreement. This is because move discussions are not a vote; it is important to be reasonably sure that there is little or no chance of accidentally excluding significant input or perspectives, or changing the weight of different views, if closed early. Especially, closers should beware of interpreting "early pile on" as necessarily showing how a discussion will end up. This can sometimes happen when a topic attracts high levels of attention from those engaged (or having a specific view) but slower attention from other less involved editors, perhaps with other points of view. It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to avoid precluding significant input and as a courtesy to ensure that it really will be a snowball.

Determining consensus

Shortcut

Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Misplaced Pages community in general as reflected in applicable policy, guidelines and naming conventions.

Shortcut

No minimum participation is required for requested moves. If no one has objected, go ahead and perform the move as requested unless it is out of keeping with naming conventions or is otherwise in conflict with applicable guidelines or policy. Further, any move request that is out of keeping with naming conventions or is otherwise in conflict with applicable guideline and policy, unless there is a very good reason to ignore rules, should be closed without moving regardless of how many of the participants support it. Remember, the participants in any given discussion represent only a tiny fraction of the Misplaced Pages community whose consensus is reflected in the policy, guidelines and conventions to which all titles are to adhere. Thus, closers are expected to be familiar with such matters, so that they have the ability to make these assessments.

If objections have been raised, then the discussion should be evaluated just like any other discussion on Misplaced Pages: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority). However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if no consensus has been reached, the closer should move the article back to the most recent stable title. If no recent title has been stable, then the article should be moved to the title used by the first major contributor after the article ceased to be a stub.

Shortcut

Note that according to Misplaced Pages:Consensus § No consensus:

“ When article title discussions end without consensus, the applicable policy preserves the most recent stable title. If there is no prior stable title, then the default is the title used by the first major contributor after the article ceased to be a stub. ”

Therefore, if a page has been moved from a long-standing title, and it is not possible to move the page back to its original title during the discussion, the default title will be the title prior to the contested move. For example, if an article is created at Soda can and stays there for years prior to being WP:BOLDly moved to pop can, and a move request is filed leading to a decision of "no consensus", the article must be moved back to its longstanding title. This is the case even if the original page was placed at pop can or fizzy drink can or orangutan-flavored soft drink can, as long as soda can took over through consensus and can be determined to be the actual long-standing title.

Relisting

For the instructions on relisting move discussions, see Misplaced Pages:Requested moves § Relisting a requested move.

Relisting is an option when a discussion cannot otherwise be closed, usually due to lack of consensus. Editors are under no obligation to wait to close a move request after it is relisted. Once a move request has been open for the full seven days, it may be closed at any time by an uninvolved editor. Closers wait mainly for general agreement, for consensus, to emerge.

Exception: if a page is added while relisting. Sometimes editors may not realize that to move page A to B, page B must first be moved to C. When a new page move request is added to one that is already seven days old, the RMCD bot places the notification tag on the newly added page that day, and the discussion must go a full seven days (more) before being closed. It is helpful to closers when relisters leave a note just below the nomination that this happened.

Relisting and participating

A relister may later become a participant or closer in the requested move discussion or survey.

Only move involved pages

A move request about moving X to Y should never be closed in such a way as to require page Z to move if Z wasn't listed in the original move request (see below).

Where a discussion would result in the original title pointing to a "Foo (disambiguation)" page, the practice of pagemovers has been to immediately move the disambiguation page to the base page name, per WP:MALPLACED. This is because a disambiguation page is presumed to belong at the base page name unless that title is taken by a primary topic.

Write a clear, concise closing statement

Shortcut Further information: § Determining consensus

There are generally three different outcomes for consensus in requested moves. The closer should clearly show which outcome has taken place so that other editors may quickly see the progression of consensus regarding the title; it is much easier to move an article that has never had a firm consensus about the title.

  1. Moved (or consensus to move) should be used when consensus is found to rename the page. If there is any question whatsoever as to which title it should be moved to, please note this in the closing summary (e.g. "moved to Squeezy José"). This almost always sets a consensus for the new title, and further requests to move the page are likely to fail unless new information or arguments are brought forth.
  2. Not moved (or consensus not to move) should be used when a consensus has formed to keep the current title and not rename the article(s) in question. For instance, a proposal to rename Bob Dylan to Squeezy Joe would likely result in everyone (or nearly everyone) agreeing that the proposed move should not take place; this notifies other editors that they should probably not propose this move in the future until and unless circumstances change. There is a positive consensus found, and that consensus is for the page to stay exactly where it is.
  3. No consensus should be used when there is neither a consensus to move nor a consensus to keep the current title. This may be because a discussion has fractured into several possible titles and none seem especially suitable, or simply because equally strong arguments and appeals to Misplaced Pages policy and outside sources were found on both sides, without any clear reason to move the page found in the discussion. Of course, as elsewhere on Misplaced Pages, this usually means that no action is to be taken at the present time.

While it is usually bad form to re-request a move if consensus is found against it (until and unless circumstances change), it is not considered bad form to re-raise a request that found "no consensus" to move. (Successful move re-requests generally, though not always, take place at least three months after the previous one. An exception is when the no-consensus move discussion suggests a clear, new course of action.)

Discussions involving multiple options

See also: WP:Bartender Shortcuts

Most move requests are simple. Alice proposes that we move X to Y. Bob, Carol and Dave chime in. Edgar analyzes the discussion and decides whether there is a consensus, and then gives one of the three outcomes above.

But sometimes things get complicated. Alice proposes moving X to Y, but then Bob raises real concerns about Y, and proposes Z instead. Carol says, no, we should stay with Y. Dave says we actually need to keep the article at X. Edgar shows up and is very confused. What does he do?

If you as a closer are in doubt because too many titles have been proposed and there's no real consensus anywhere, it is generally best to close as no consensus and allow someone to re-propose the move to a more specific or better title.

Shortcut

But then again, there are situations where multiple names have been proposed and no consensus arises out of any, except that it is determined that the current title should not host the article. (There are good arguments for Y, and there are good arguments for Z, but there are virtually no good arguments for it to stay at X.) In these difficult circumstances, the closer should pick the best title of the options available, and then make clear that while consensus has rejected the former title (and no request to bring it back should be made lightly), there is no consensus for the title actually chosen. Because such closures are inherently complex and require the closer to use more independent judgment than normal, it is strongly encouraged to provide an explicit closing statement in such closures. As this result does not indicate a consensus for the chosen title, anyone who objects to the closer's decision may make another move request at any time, and is advised to create such a request instead of taking the closure to move review.

Closing the requested move

When you complete an entry on the project (whether the move was accepted or rejected), remove the {{requested move/dated}} tag from the talk page, or change {{requested move/dated}} to {{subst:requested move/end}}. You should also add and sign a comment to indicate whether the move was accepted or rejected in the discussion area for the requested move. To ease things a little bit, there are several scripts that can help, with the most common being User:TheTVExpert/rmCloser (followed by User:DannyS712/PageMoverClosure and User:Andy M. Wang/closeRM).

While historically, there have been other options for closing the move request survey on the affected article's talk page, nowadays we exclusively use the twin templates {{subst:RM top|result of the discussion.}} and {{subst:RM bottom}}.

Step-by-step closing procedure

After clicking the tab next to the move discussion, you may follow these step-by-step instructions for closing an RM discussion:

Before closing After closing Description
==Requested move== ==Requested move== Leave the heading alone; the close starts below it.
{{Requested move/dated|Foo}} {{subst:RM top|'''RESULT.'''|pmnac=yes}} Replace text on left with text on right.
DISCUSSION DISCUSSION Body of the discussion stays unchanged.
{{subst:RM bottom}} Add the bottom template.
  • If additional explanation is provided as to why you have closed the move discussion as a certain result, add additional comments immediately after '''RESULT'''..
  • Save the page with an edit summary such as "Closing requested move survey; page moved/not moved".

After closing, the page should look similar to this:

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: RESULT. . (non-admin closure) Example (talk) 19:13, 2 January 2025 (UTC)

Foo → Foobar – rationale of nominator. Example (talk) 19:13, 2 January 2025 (UTC)

  • Supports/Opposes with discussion
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.

Add {{Old moves}} to the talk page if so desired

After the move is complete, the {{Old moves}} template may be added to the top of the talk page (or updated if already present), allowing editors to see previous move discussions that might otherwise be archived. This is helpful for titles that are likely to be challenged again, so that any would-be re-proposer can make reference to previous arguments and consider how a consensus may be formed to move. In the case of pages with multiple move discussions, these templates should always be added/updated after the closure of an RM.

Automatic removals

Once the article's talk page has been updated, there's no need to return to the Misplaced Pages:Requested moves page and delete the article's entry there; this will be performed automatically by a bot.

Likewise, RMCD bot will remove the {{Title notice}} from the page itself within 15 minutes.

Using move protection during RMs and immediately after RM closes

See also: WP:MOVP

Some RM discussions are contentious; undiscussed, unilateral page moves during a discussion or page moves made immediately after and contrary to an RM close decision are disruptive and hurt the integrity of the RM process. Admins monitoring RM discussions should use their discretion to move protect articles during contentious RM discussions when they believe a premature, undiscussed unilateral move would be disruptive to the discussion. The same discretion should be used to start or continue move protection immediately after the RM close. Generally, such move protection should be limited to no more than 30 days under normal circumstances. The RM closing comment should reference the move protection.

Moving procedures

Edit history of destination page

The majority of target names for move requests already exist as redirects to the present names. Whether a redirect or otherwise, that existing target title should be investigated to see whether it has a minor or major page history. If it has a minor page history, generally meaning it only existed as a redirect, and was never a duplicate article, never had content that was cut and pasted to the present title, nor merged there, it may simply be deleted. However, if the target page title has a major history it should never be simply deleted, as we need to retain such page histories for proper copyright attribution. There are three ways to deal with target pages with major histories, dependent on circumstances. In the event this situation presents itself on a move, click "show" below for instructions.

Procedure for redirects with major histories
  1. For page histories resulting from cut and paste moves, the correct way to fix this is to merge the page history of the present article and the redirect, using the procedure outlined at Misplaced Pages:Administrators' guide/Fixing cut-and-paste moves. On rare occasions, this procedure will not work correctly. Once a history merge is done, it cannot easily be undone, so don't pick this option unless it is definitely the right one. You can request history merges at Misplaced Pages:Requests for history merge.
  2. For duplicate articles and merged content, or alternatively for cut and paste moves, the page histories of the article and the redirect can be swapped with a round-robin move. For cut and paste moves this leaves a bifurcated history, but has less chance of causing problems. Simply move the redirect with a major history to a temporary name (Draft:Move/NAME is suggested), suppressing the creation of a redirect (in the event you forget to suppress the redirect, delete the same); next, move the article to the move target location, again suppressing the redirect and deleting the same if you forget; next, move the redirect from its temporary location to the title at which the article you just moved was formerly located. At this point the redirect will be pointing at itself; re-target it to point to the new location of the article. See also WP:SWAP and WP:ROUNDROBIN.
  3. Another option is for redirect pages with major histories to be archived into a talk namespace, and a link then placed on the article's talk page. (An example of such a page is at Talk:Network SouthEast, which was originally created as a duplicate article at Network SouthEast and later archived, when the original article was moved from Network South East).

Cleaning up after the move

Main page: Misplaced Pages:Cleaning up after a move

You should not close any move if you are unwilling to do the necessary clean up tasks described at WP:POSTMOVE. Some of the most commonly required cleanup tasks are:

  • Updating the article prose (including the first sentence) to use the new name
  • Updating any navigational templates to link directly to the new title, rather than via a redirect
  • Fixing any mistargeted wikilinks resulting from the move (only applies when the move involves a change to primary topic)

Moves of other pages

Shortcut

If a page is to be moved as the result of a move request, mention should be made of this in the move proposal and a notice should be placed on the talk page of the article to be moved (unless of course it is hosting the discussion). Generally, a move request on whether to move X to Y should have no impact on page Z's title, unless it is initiated as a {{multi-move request}} that mentions moving Z as a possibility. This is because the editors most interested and aware of Z are not able to contribute their expertise to the naming discussion, since it's happening at a different place without any notice given.

These situations often come up when Foo (barge) is proposed to move to, say, Foo (enormous sailing thing), and someone mentions that they think the barge is actually the primary topic. A consensus of these barge enthusiasts may then informally suggest that the existing article Foo be moved to Foo (bar), without actually notifying Foobar-interested editors by signaling at Talk:Foo that a move request involving that page is taking place. This often leads to strife and another, more contentious move request. If consensus at X signals that Z should move, close the request at Talk:X, do not move Z, and file a new move request at Talk:Z.

Even if consensus is clear, when closing a move request do not move articles that have not been nominated to be moved except in the very clearest and not-even-plausibly controversial situations.

Bot considerations

Please report unresolved incidents at User talk:RMCD bot.

Malformed requests

A request will be listed in a special section titled "Malformed requests" on Misplaced Pages:Requested moves when the listing bot fails to successfully interpret the request. Please remember to use {{subst:Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:

  • The request was appended to an existing talk page section. Add a new section header immediately above the {{Requested move/dated}} template.
  • It is OK to change the auto-generated level 2 header to a level 3 header, thus making the RM section a sub-section of an earlier-started discussion.
  • The page requested to be moved is a redirect. Only pages with non-redirecting content should be requested to be moved.
  • Per WP:SIGPROB the timestamp must adhere to the system-generated format (HH:MM, D MM YYYY (UTC)) and must not be customized.

"Time could not be ascertained"

A request will be listed in a special section titled "Time could not be ascertained" on Misplaced Pages:Requested moves when the listing bot cannot ascertain the date on which the request was made. Please remember to use {{subst:Requested move}} – rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:

  • The move request is not signed. Sign the move request, and the problem is solved. If you are signing for someone else and you use {{Unsigned}}, you must place today's time/date stamp for this to remedy the problem, so you can use the form {{subst:unsigned|Foo|~~~~~}}, and note this uses five tildes to place the time stamp, or the actual timestamp can be copied from history - but adding (UTC) is required.
    Also remove the <!-- Template:Unsigned --> comment from the end of the line – the bot allows up to 23 bytes following the timestamp at the end of the line, and that comment is 26 bytes long.
  • A missing "–" (endash) between the proposed move and the proposal description will prevent the description from appearing. This can be fixed by simply adding the missing endash.
  • Unusually formatted signatures will prevent recognizing the end of the proposal description, for example, if the date is formatted Month Day, Year instead of Day Month Year. This can be fixed by editing the timestamp or adding a formatted time stamp. In the first case, December 20, 2012 was changed to 20 December 2012, in the second case, a second time stamp was added.

Header confusion

Occasionally two sections with the same section heading will appear on a talk page. When this happens, the bot will link to the first one, even if the current move request is the second one. This can be remedied by giving the section containing the current move request a different name, such as "Requested move 2", or by giving the older section a different name, like "Requested move (month year)". A duplicate header for the same discussion can be deleted.

Notes

  1. Note that these criteria are significantly stricter than the criteria listed at WP:INVOLVED; this is intentional, befitting the less urgent nature of requested moves.
Categories: